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ABSTRACT 

Tc  realize  the  full  perfcrmance  capabilities  of  th9 
Elock  1C  version  of  the  surface  launched  HABPOON  cruise 
missile,  modifications  have  been  directed  on  the  HABPCON 
Shio  Command-Launch  Control  Set  (HSCLCS) ,  AN/SWG- 1  (V) .  The 
pur-cse  of  this  thesis  is  to  begin  the  design  of  modules  for 
a  simulation  model  which  meets  the  specification  require- 
ments of  the  HSCLCS.  These  specifications  are  derivsd  from 
stated  U.S.  Navy  requirements,  some  additional  features 
proposed  ty  the  author,  and  features  proposed  in  a  previous 
thesis.  The  simulation  model  can  then  be  used  for  testing 
and  evaluating  the  proposed  modifications  and  for  training 
purposes. 
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I.    INJRODOCTIOH 

With  the  introduction  of  additional  performance  capabil- 
ities in  the  Block  1C  version  of  the  HARPOON  cruise  missile, 
the  present  HARPCON  Ship  Command-Launch  Control  Set  (HSCLCS) 
has  crcven  to  be  inadequate  for  controlling  this  new  HARFCON 
missile.  Therefore,  modifications  have  been  directed  by  ths 
Chief  of  Naval  Operations,  to  take  advantage  of  these 
supolemenTary  features.  The  system  spscif ications  have  baen 
sat    forth   hy   Naval    Ssa  Systems    Command. 

Since  the  HSCLCS  must  be  redesigned  to  facilitate  the 
system  s.-recifications,  it  is  readily  apparent  that  a  simula- 
tion model  should  be  developed  to  test  the  system  specifica- 
tions and,  once  determined  to  be  a  usable  model,  to  be 
further  used  for  training  purposes.  The  development  of  such 
a  mode.l  allows  an  experimenter  to  play  with  the  system,  and 
investigat.e  potential  problem  areas,  as  well  as,  encourage 
the    process   of    innovation. 

In  desicning  a  simulation  model  of  a  real  system,  the 
goal  should  be  to  conduct  testing  to  understand  the  behavior 
of  the  system  or  to  evaluate  various  strategies  of  system 
oceraticn  under  consideration.  A  further  goal  should  be  for 
the  model  to  be  used  for  training  purposes  when  it  is  not 
feasible  or  cost  effective  to  use  the  real  system.  The  art 
of  modelir.g  encompasses  the  ability  to  classify  the  problem, 
abstract  the  essential  features,  and  then  elaborate  on 
these,  to  produce  a  model  where  useful  approximation 
results.  Special  care  must  therefore  be  taken,  to  ensure 
that  the  model  is  an  accurate  and  viable  representation  of 
the  real  system.  To  meet  this  end,  certain  criteria  must  be 
mat  in  support  of  the  development  of  a  proper  simulation 
model,    including: 

a.      ease   in   understanding   by   the   user. 


b.  a    purpose    or  goal    directed  model. 

c.  ease  of  control  and    manipulation   of   the    model. 

d.  model    completeness    on   important   issues. 
€.      no   allowance   for  nonsense  answers. 

f.      ease  of  model  modification. 
Keeping   these  criteria    in   mind,    and    realizing    that    simu- 
lation  modeling      is    a   learning      process,      the   task      cf    model 
develcoment    may    begin. 
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II.     BAHPCOH  SHIPBOABE   COMM  INPziMICH    COHTHOL   SET     (HSCLCS) 

sPECiFicarioHs 

This  chapter  will  summarize  the  system  specifications  as 
set  forth  in  Reference  1,  and  as  developed  by  Reference  2 
and      Reference    3.  This   phase     will      present   the      existing 

svstem,      the     needs    cf  the      existing    system,        and  technical 
constraints   imposed    en  hardware   and    software   considerations. 

A.       FBESEIT    HARPQOH    REAFON    STSTES    (HWS) 

The  HAREOON  Weapon  System  (HWS)  was  developed  to  meet 
the  needs  cf  the  Navy's  anti-ship  mission.  This  system  is 
deployed  en  fast  attack  submarines,  several  type  aircraft 
and  surface  combatants.  The  HWS's  purpose  is  to  provide 
all-wearher ,  ov?r  the  horizon,  day /night  anti-ship  capa- 
bility. It  is  composed  of  the  missile  subsystem,  the  asso- 
ciated launcher  subsystem  and  the  command  and  launch  control 
subsystem.  This  thesis  shall  be  primarily  concerned  with 
the    latter. 

The  BARPOON  missile  utilizes  an  in  flight  low-level 
traiectory  with  a  pop-up  feature  during  it's  -terminal  phase. 
It  has  an  active  radar  seeker  with  counter- counter  measure 
capability  to  assist  in  attacking  over  the  horizon  surface 
targets. 

In  the  ship-launched  version,  the  HARPOOM  missile 
utilizes  either  third  party  or  onboard  sensor  data  for 
targeting  purposes.  Then,  since  the  missile  requires  no 
further  information  after  launch,  it  is  considered  a  "launch 
and    forget"   type   weapon. 
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Fcr  t^e  shipboard  configuration,  the  HWS  data  prccassing 
and  con-rol  functions  are  provided  by  the  HSCLCS.  The  HSCLCS 
has  three  operating  modes:  casualty,  normal,  and  training. 
In  the  normal  mode,  the  HSCLCS  provides  rhe  following  major 
functions: 

-  Distribution  of    power  to   various    HWS   sguipment. 

-  Selecticn  and   application   of   missile   warmup   power. 

-  The  ability  to  conduct  various  automatic  and  manually 
initiated  tests  which  confirm  the  operability  of  -he 
HSCLCS. 

-  Selection,  transfer,  processing  and  display  of  target 
data. 

-  Coordination  of  the  selection  of  tactical  missile  mode 
and   type  of    fusing. 

-  Selecticn  of  the  launcher  cell  containing  the  intended 
HAHFCCN    missile. 

-  Initialization  of  the  selected  missile  and  the  supervi- 
sion of  the  exchange  of  data  between  the  missile  and 
other   HWS  eguipmert. 

-  Ccntrol   of    all    missile    firing  activities. 

These  functions  are  carried  out  primarily  by  the  HABPCON 
Ccntrol  Console  (HCC)  and  the  Weapon  Control  Indicator  Panel 
(WCIP)  . 

The  HCC  encompasses  most  of  the  system-unique  command 
and  launch  subsystem  equipment.  This  includes  the  Data 
Processor  Computer  (DPC)  ,  a  16  bit  microcomputer,  and  a  Data 
Conversion  Unit  (DCU) ,  an  analog  digital  converter.  These 
two  components  perform  dara  conversion  and  processing,  and 
provide  an  interface  with  current  ship  sensors  or  external 
eauicment. 

The  WCIP  provides  the  operator  with  visual  status  infor- 
mation of  the  fire  control  solution.  It  further  provides 
the   operator  with  manual  input   capability. 
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The  DEU  executes  an  assembly  languaga  program  to  prcvid=r 
the    following  services: 

-  Validation    of   launch   envelope  parameters. 

-  Missile  command  generation  for  implementation  of  missile 
control  parameters  including  ship's  attitude,  s=arch 
pattern  orders,  engine  starting,  flight  termination 
range,  altimeter  setting,  and  various  selectable  flight 
traiectcry   and    maneuvering  modes. 

-  Missile   testing    prior  tc   launch. 

-  Fr9-launch    sequencing   and   timing. 

-  Data    formatting   and   transfer    synchronization. 

The  DCU  proc9sses  all  digital  and  analog  signal  conver- 
sion. It  further  provides  interfacing  of  target  data  inputs 
for  the  Naval  Tactical  Data  System  (NTDS)  and  it  also 
provides    for  ship   motion   parameter  conversion. 

E.       COBBEHT    DEFICIENCIES    IN    THE    HSCLCS 

With  the  introduction  of  new  enhancements  in  th«  HABPCON 
missile,  new  command  and  control  problems  have  also  been 
introduced.  The  current  WCIP  cannot  accommodate  these  new 
capabilities.  Further,  the  operator  is  not  provided  with 
sufficient  facilities  to  direct  and  execute  a  well-planned 
BARPOON  attack.  These  new  capabilities  mandate  a  substan- 
tial change  in  the  hardware  and/or  software  of  the  existing 
HSCLCS.  Since     current      software    is      written      in      machine 

language,  it  is  extremely  machine  dependent.  This,  coupled 
with  the  added  difficulty  that  different  hardware  configura- 
tions exist  for  subsurface,  surface  and  air  launches, 
further  compounds  the  problem  of  software  standardization. 
Beference  2  and  Reference  3  set  forth  existing  deficiencies 
in   the   current    HSCLCS.      These   include: 

-  Full  tactical  ccntrcl  of  missile  variants  (the  pre- 
launch  selections)  are  not  available  to  the  existing 
WCIP. 
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-  The  WCIP  provides  inadequata  control  for  a  well 
coordinatsd,  mul-i-ship  or  multi-platform  attack  agair.s- 
a   single  surface   target. 

-  The  WCIF  provides  inadequate  control  for  a  multi-missile 
(SALVO)    attack   agains-    a   single    surface   target. 

-  The  WCIP  does  not  incorporate  existing  intelligence 
information  (e.g.,  target  class,  course,  speed,  sector 
of   vulnerability)    into    the   engagement    planning   process. 

-  No   computer-aided  engaged    planning   is   implemented. 

For  engagement  planning,  the  HSCLCS  has  the  following 
deficiencies: 

-  Insufficient  infcrmaticn  is  displayed  at  the  WCIF  to 
permit  the  operator  to  evaluate  the  quality  of  an 
enqacement    plan     (e.g.,    probability  of   acquisition). 

-  Insufficient  information  is  displayed  at  the  WCIP  to 
rrovide  accurate  data,  implying  risk  to  unintended 
targets  during  booster  drop,  flyout  and  target 
acquisition. 

-  The  HCIP  provides  no  display  of  planned  trajectory, 
flight    path    or    seeker  search   patterns. 

-  The  HSCLCS  does  not  provide  computer-aided  engagement 
plan   quality  and   safety    analysis. 

-  The  WCIP  provides  no  status  information  on  available 
missiles  and  associated    launcher. 

-  Only  track  data  for  one  track  can  be  stored,  with  no 
capability    for    multi-track  retention. 

-  No  means  are  currently  available  to  provide  corrections 
essential  to  missile  performance  for  the  environmental 
parameters    such   as  wind,    rain  and    sea   state. 

With  these  deficiences,  the  training  mode  is,  at  best, 
minimal.  Since  there  is  a  general  lack  of  realism,  espe- 
cially in  the  graphical  representation  of  the  engagement 
picture,  the  operator  has  little  ability  or  inclination  to 
improve    his   proficiency. 
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C.   BSS  CCSSTBAIHTS 

Modifications  to  the  HSCLCS  should  take  advantage  of, 
but  net  necessarily  be  limited  to,  the  following  new  missile 
capabilities: 

-  Wayccint  selecticn. 

-  Hange   and  bearing    (RBL)       search   pattern   expansion   direc- 
tion  selection. 

-  Terminal  attack    mode   selection. 

-  Maximum   range  increase. 

-  High-al^.itude   flycut 

-  Fre-search    sea    skim. 

With  these  capabilities  in  mind.  Reference  1  has  set 
forth  the  modification  and  specification  limitations  of  each 
of  the   ccmpcnents   in   the   HSCLCS. 

1.  HflRrOON    Control    Console    (HCC) 

The  HCC  may   be  modified  as  required  to  acccmmcdate 

* 

power  and  digital  interfaces  to  ths  WCIP,  and  to  provide 
intearal  mounting  with  the  WCIP.  In  addition,  the  HCC  must 
meet    the   specification  requirements   of   Appendix  C. 

2.  P§ta  Conversion    Unit    (DCU) 

The  DCU  modifications  are  limited  to  the  removal  of 
circuit  cards  in  order  to  provide  required  functions  for  the 
WCIP.  It  will  provide  an  interface  with  the  ship's  motion 
systems,  tcirget  detection  systems  and  missile  launch 
equipment. 

3  •      Data  Processor  Computer    (DPC) 

The  DPC  is  a  general  purpose  computer  with  ultra- 
violet erasable  programmable  read-only  memory  (OV-EPEOM)  . 
This  computer  provides  weapon  control  solutions  to  the 
missile    and    provides     direct   real   time   control     of   the    WCIP. 
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It  alsc  conducts  interlock  ccmpu-ations  to  prevent  launch 
when  the  ship  roll  and  pitch  are  excessive,  launcher 
pointing  and  stabilization  orders  and  conducts  self-tes-ing 
en  the  WCIF  or  HARPOCN  missile  when  directed.  The  modified 
EPC  shall  consist  of  (a)  a  new  central  Processing  Unit 
(CPU)  ,  which  will  provide  the  computational  speed  required 
of  the  WCIP  engagement  planning  functions,  (b)  a  minimum  of 
110,000  sixteen-bit  words  of  OV-EPROM,  16,000  sixteen-bit 
words  of  random  access  memory  (RAM),  and  2,000  sixteen-bit 
electronically  erasable  programmable  read-only  memory,  and 
(c)  an  RS  232  serial  interface  for  use  with  external  devices 
providing  training  or  data  extract  functions.  The  DPC  may 
be  further  modified  tc  support  the  engagemem:  planning  func- 
tions  as   specified    in   Appendix   C. 

4.      Weacons      Control-Indicator     Panel         (WCIP)         Graphic 
Pi§£l§2   Sys-eir 

The  WCIP  Graphics  Display  System  (GDS)  shall  consist 
of  a  plasma  graphic  display  with  embedded  microprocessor  and 
twenty  manual  entry  buttons  under  software  control.  This 
function  will  allow  the  operator  to  plan,  evaluate  and 
execute  a  HARPOON  engagement  and  to  conduct  training.  The 
disolay  is  to  provide  the  operator  with  a  visual  depiction 
of  the  tactical  engagement  situation  and  concurrent  readouts 
of  necessary  engagement  data.  It  is  noted  that  a  prototype 
disolay  has  already  been  developed,  and  is  currently  under 
evaluation. 

5-      Weapon   Ccntrcl-Indicatcr   Panel 

The  WCIP  will  be  required  to  provide  all  the  func- 
tions of  the  specifications  listed  in  Appendix  C.  It  must 
provide  operator/HSCLCS  interactive  functions  required  for 
engagement  planning.  It  will  provide  visual  status  informa- 
tion   en      the  HARPOON    missile     and   launcher,      and      the   manual 
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con-rcls  for  selecting  missile  initialization  functions/ 
parameters  and  firing  of  all  HARPOON  missile  variants. 
Although  target  data  entry  for  missile  initialization  is 
normally  automatic  through  the  DCU,  alternate  manual  entry 
must    te    provided   for    from  the    WCIP. 

D.       PBOPCSED  SOFTWARE   PLAN 

Reference  2  and  Reference  3  set  forth  consecutive 
r-=finements  to  a  software  plan.  A  reguiremen-^s  analysis  was 
conducted  to  provide  a  foundation  for  the  flow  and  structure 
cf  information  and  to  identify  interface  details  within 
existing  design  constraints.  To  accomplish  this  analysis 
the  use  cf  a  data  flow  diagram  (DFD)  was  used.  This  type  of 
diagram  is  a  graphical  aid  for  demonstrating  data  flow 
during  ths  designing  cf  a  software  system.  A  general  outline 
cf  a  DFD  consists  of  the  following: 
1-      PfP   Ait^ibiites 

-  Information  flow  can  be  represented  by  a  DFD  for  any 
system. 

-  Each  transformation  in  a  DFD  may  require  refinement 
to  realize  a  complete  understanding  cf  the 
"transformation. 

-  Data  flow  must  be  emphasized  without  regard  to 
control    of  data. 

2.       DFD    Symbols 

-  Information  flew  is  identified  by  a  labeled  line  from 
the  source  to  the  sink  with  an  arrowhead  pointing  in 
the    direction   of   flow. 

-  Data  transformation    is   represented   by  a  circle. 

-  Information  sources  and  sinlcs  are  displayed  as 
rectangles. 

-  Stored  information  (i.e.,  data  bases  and  files)  are 
represented    by  two  parallel   lines. 
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3  .      DFC    Usage   Guidelines 

-  Tt€    first   layer  of   the    CFD  is    the   system   module. 

-  The  second  layer  of  the  DFD  is  a  generalized  cvsrview 
of   the    DFD. 

-  All  items  in  the  DFD  including  arrows  must  be 
labeled. 

-  Information  continuity  is  required  for  all  DFD 
refinements. 

-  Refine  only    one   item   at  a    time. 

-  When  uncertainty  exists  as  ro  whether  further  refine- 
ment,  assume    that   the    possibility  exists. 

-  Fellow  data    flow   from  left   to    right. 

-  A  transformation  may  output  control  data  for  a  subor- 
dinate module.  This  control  data  does  not  represent 
control    structure  and   therefore   is  not   control   flow. 

Figures    2.  1    through   2.4      represent    a   refined    development 
of   the   HSCLCS   by   the    data   flow   method. 
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III.    MODELING    PROCESS 

In  creating  a  simulation  model  of  the  HSCLCS,  the 
assuurt icn  is  made  that  the  simulation  will  ba  used  to 
examine  the  properties  of  the  HSCLCS,  and,  if  found  depen- 
dable, used  as  a  training  device.  In  developing  this  model, 
a  number  cf  intermediate  steps  may  be  identified  to  assist 
in  -he  model  development.  Several  of  these  steps  will  be 
develcrsd  here,  but  others  must  wait  until  actual  model 
implementation    conducted   under   other    theses. 

I.       SYSTIB    DEFIHITIOH 

At  this  step  of  the  modeling  process,  a  determination 
must  te  made  of  the  boundaries  (i.e.,  what  will  be  simu- 
lated) utilized  in  developing  the  system.  Since  a  formula- 
tion of  the  siiulaticn  model  may  change  as  it  is  being 
developed,  the  conditions  set  forth  at  x.his  step  cannc-c  be 
considered   solid.  As   new      information    becomes      available, 

these   conditions  must  be   amenable    to   change. 

The  HSCICS  is  a  lajcr  component  of  the  HARPCON 
Heaoon  System  (HWS)  comprised  of  two  elements:  the  HABPCON 
Control  Console  (HCC)  ,  and  the  Weapon  Control  -  Indicator 
Panel  (WCIP).  It*s  primary  purpose  is  to  provide  the  capa- 
bility to  initialize  and  launch  existing  HARPOON  missiles. 
In  it*s  present  configuration,  the  HSCLCS  provides  a  weapon 
control  solution,  missile  initialization,  launcher  control 
and  missile  firing  functions.  With  new  modifications,  the 
HSCLCS  should  also  provide  engagement  planning  and  data/ 
training   extract   capability. 
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The  HCC  perfcrms  most  of  ths  data  processing  and 
conversion  necessary  for  missile  launch.  The  WCIP  provides 
visual  information  tc  the  operator  during  the  fire  control 
solution  formulation,  and  further  provides  for  manual 
conxrol  ty  the  operator.  In  the  simulation  model  develop- 
ment, it  would  appear  that  the  HSCLCS  would  be  the  sole 
cbiect  of  simulation.  However,  since  the  HSCLCS  obtains 
information/data  from  other  ship  sensors  or  from  proposed  or 
current  manual  input,  the  model  must:  allow  for  input  of 
simulated  ship  sensor  information/data  either  manually  or 
automatically. 

2.      Model  Formulation 

The  next  task  is  that  of  model  formulation:  reduc- 
tion of  the  real  system  to  some  logical  flow  pattern.  The 
modal  formulation  should  neither  oversimplify  the  system  nor 
overspecify  it  so  as  to  appear  awkward  or  become  extremely 
expensive.  The  latter  case  is  usually  the  problem  area.  In 
this  simulation,  the  model  may  be  necessarily  bulky  due  to 
the   need   to   simulate   the    entire   HSCLCS   subsystem. 

In  setting  forth  the  modal  formulation,  certain 
criteria  must  be  incorporated  tc  ensure  a  good  simulation. 
Because  the  final  result  of  this  simulation  is  to  be  more 
alonq  the  line  of  a  prototype  development  that  as  an  anal- 
ysis tocl,  the  initial  structure  for  the  model  formulation 
as  set  forth  in  the  data  flow  diagrams  of  Chapter  2  can  be 
used.  It  would  then  appear  that  each  of  the  boxes  in  the 
data  flow  diagrams  can  be  developed  inro  a  module  for  the 
simulation.  Several  criteria  are  met  for  a  good  simulation 
by   proceeding  in  this   manner. 

The  first  criteria  is  that  the  model  becomes  easily 
purpose  or  goal  directed.  Each  module  will  be  developed  to 
carry  out  a  specific  task.  If  the  desired  goal  of  the  model 
changes,      sudi      as    for  training,        then    a   minimum      number   of 
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chanaes  will  be  required.  This  coincides  with  the  iirpcrrant 
criteria  of  model  ncdificaticn.  Through  the  creation  of 
modules  from  the  data  flow  diagrams,  using  the  transaction 
transform  analysis  methodolcgy  described  in  Reference  4,  the 
effects  of  any  changes  to  either  the  design  specifications 
or   to    the  system   design   will  be   minimized. 

Modularization  can  also  lead  to  ease  of  conxrol  and 
manioulaticn  of  the  model.  If  the  modules  are  developed 
correctly,  that  is,  through  proper  abstraction  and  good 
interfaces,  then  the  designer  will  only  need  to  know  what 
the  mcdul<=  does  and  not  necessarily  how  it  does  it.  This  in 
turn  leads  to  a  better  underszanding  of  the  sysrem  by 
reducing  the  complexity  at  each  level  of  the  model.  This 
will  further  allow  ease  in  determining  completeness  on  all 
important   areas    of   the   model. 

ether  criteria  for  a  good  simulation  must  be 
comoleted  at  the  implementation  stage  of  model  development. 
These  include  ease  in  understanding  by  the  user  and  no 
allowance  fcr  nonsense  answers.  The  former  will  require 
carefully  designed  interaction  with  the  user,  whereas  the 
latter   will   require    input    parameter  checking. 

In  a  general  overview,  the  model  can  probably  best 
he  split  into  4  modules:  a)  data  processing  unit  (DFD)  ,  b) 
data    conversion  unit (DCa) ,  c)  weapons  control- 

indicator  (WCIP)  panel  graphics  processor  and  d)  weapon 
control-indicator  panel  controls.  The  main  desire  is  to 
check  the  use  of  the  WCIP  graphics  processor  and  ccntrols, 
however,  since  much  of  the  input  is  through  The  DEC  and  DCU, 
they  too  will  have  to  be  simulated.  The  DPU  and  DCD  may 
carry  the  added  burden  of  simulating  the  ship  sensors,  or 
may    solely      provide    data   in      a    refined   form.  The   graphics 

processor  will  probably  be  the  most  difficult  to  simulate, 
and  may  not  in  fact  be  completely  necessary.  However,  to 
ensure  some  sense  of  reality,  the  graphics  module  should 
closely   model  an   actual   display. 
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since  a  first  design  refinement  of  the  sys-em  has 
already  teen  made,  Bef.  3  there  appears  to  be  no  real  need 
tc  make  major  changes  at  this  point.  Now  the  task  of 
definina  the  structures  for  the  data  bases  identified  in 
Acpendix  D,  and  the  modules  identified  in  Appendix  E,  can  be 
made  . 

3.      Datatases 

All  of  the  data  bases  in  Appendix  D  appear  to  be 
sufficient  for  the  simulation.  This  assumption  does  not, 
however,  prevent  changes  in  later  stages  of  the  model  devel- 
or^ment.  If  an  element  in  the  data  base  requires  a  default  or 
initial  value,  it  will  be  accomplished  by  one  of  the  modules 
listed   in    Acpendix    E. 

a.      Environmental  Data   Base 

The  Environmental  Data  Base  is  used  to  store 
informaticn  about  current  weather  conditions,  to  be  used  in 
obtaining  a  practical  engagement  solution.  This  data  base 
will    always     reside    in  main    memory.  It    will  consist      of  a 

single   record  with    eight   fields: 


Visibility 
Sea   State 
Wind   Direction 
Hind   Speed 
Relative    Humidity 
Temperature 
Barometric  Pressure 
Precipitation 


integer   range    0..30(miles 
integer   range    0..10 
integer   range   0. . 359  (degrees 
integer   range    0..  100  (knots 
integer   range    0. ,  100  (percent 
integer   range   -100. . 150 (degrees   F 
integer   range   900 ,. 1 100 ( millibars 


string(yes,no 
The    following   default   values      will  be    made   auto- 
matically  prior    to      any   manual   entry    from      the  operator,      or 
automatic  entry    from    selected   ship  sensors. 


Visibility 
Sea   State 
Wind   Direction 


1 
1 
00  0 
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wind   Speed 
Temperature 
Barcmatric 
PreciT3i"tation 


0 

50 

10  20 
No 


After  initialization,  the  operator  may  input  the 
current  environmental  conditions  manually  or  allow  au-omatic 
updates    from  own   ship  sensors. 

t.      Launcher   and   Missile    Status   Data    Base 

This  data  base  will  consist  of  an  array  of 
records  equal  to  tie  number  of  cannisxers  available  for 
launching  missiles.  It  will  always  reside  in  main  memory. 
Each    record   will  consist   of    the   following   four   fields. 


Launcher    Number 
Cannister    Number 
Missile   Type 
Launch    Inhibit 


integer   range    1 . . #launchers 
integer   range    1..8 
integer   range    1..7 
integer   range   0..1 
The    following   values    will   be   assigned    upon    acti- 
vation  of      the   system.      The    values     will    be   selected      from  a 
file    in    secondary     storage.         The   file   in      secondary   storage 
may    be   modified   to    accommodate   any     type   of   platform    and   any 
type    cf    missile    loadout.         When   any      changes    are    made   by   the 
oieratcr    to     the  data  base,         they  may  only      be   accomplished 
using   a   special    code. 

current   launcher   number 
current    cannister    number 
type    missile    in   current    cannister 
(a     value      of        7      indicates      the 
launcher     is   empty     and      requires 
launch   to      be   inhibited      for  that 
cannister) 
Launch   Inhibit  :      0    (inhibited) 


Launcher   Number 
Cannister    Number 
Missile   Type 
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The  size  of  the  strucxure  holding  this  data  base 
in  main  memcry  must  be  variable  to  allow  for  the  require- 
ments of  different  platforms.  One  method  to  permit  this 
would  be  to  have  the  first  item  read  from  the  secondary 
storage  file  indicate  the  size  of  the  array  (i.e.,  the 
r.umber  of  available  cannisters)  .  If  for  some  reason  the 
size  needs  to  be  changed,  such  as  for  an  inoperable 
launcher,  the  operator  will  have  the  capability  of  changing 
the   size. 

c,      Itenu/State  Data    Base 

This  data  base  will  reside  permanently  in  main 
memory.  Immediately  upon  power  up,  uhis  data  base  will  be 
initialized.  The  Control  Module  will  make  a  call  zo  the 
Hsnu/State  Display  Module,  notifying  it  that  the  current 
snate,  cr  process  instance,  is  0.  This  will  cause  the 
Menu/State  Display  Module  to  initialize  the  da-a  base  and 
enter   state    1.  The  data    base   will    consist   of      an    array  of 

records.      Several  of   the   fields      will    be   of   variable   length. 
The    fields    will    be   arranged    in  the   following   manner: 


State 

Number    Options 

Menu   Display 


integer   range    L.maxstate 
integer    1. .  maxcptions 
array    (2, Number   Options) 
Option 

Display  Location 
After  the  data  base  has  been  initialized,  the 
first  menu  that  will  be  displayed  will  be  the  main  menu. 
Thereafter,  whenever  a  menu  selection  is  made,  the  state 
will  be  identified  and  sent  to  the  Menu/State  Display 
Module. 
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d.      Ship  Parairetar    Data   Base 

The  Ship  Parameter  Data  Base  will  consist  of 
informaticn  about  the  operators  own  ship.  It  will  contain  a 
single  record  with  four  elements,  and  will  reside  in  main 
memory. 

Course  :      integer   range   0..359 

Speed  :      integer    range    O.-maxspeed 

(maxspead    is   maximum   speed  of  the 
platform   which      must    be      tailored 
for   each   individual  platform). 
Latitude  :      record 

degrees 
minutes 
seconds 
Longitude  :      record 

degrees 


integer  range  -90,. 90 
integer  range  0..60 
integer  range  0..60 


integer  range 

-180..  180 
integer  range  0. .  60 
integer  range  0. .  60 


minutes 

seconds 

All  elements  will  be  initialized  to  0  after 
which  tfce  operator  nay  input  changes  manually.  Automatic 
changes  may  also  be  made  via  ship  sensors  (e.g.,  pit  sword, 
dummy    log,    gyro,    navigation    equipment). 

e.      Threat   Data   Base 


This  data  will  always  reside  in  some  secondary 
s-oraqe  since  it  will  only  be  needed  when  requested.  The 
potential  for  this  data  base  becoming  very  large  is  readily 
apparent.  This  data  base  may  only  be  changed  with  special 
permission.  For  the  purpose  of  this  simulation  it  will 
consist   of   a  file   of    records   with   six   elements. 


Ship    Name 
Nationality 
Ship   Class 


string 
string 

string 
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W-Bapons  :      string 

ECM    E^uipient  :      string 

SnqaaBinent  Method        :      string 

All  information  in  this  data  base  may  be  changed 
by   the   operator      using  a  special   code.  The   inf ormat icn   in 

this  file  may  be  of  classified  origin.  The  data  base  should 
have  the  capability  of  being  accessed  for  specific  informa- 
tion ty  the  Ship  Name.  Further,  to  facilitate  flexibility,  a 
lisr  of  ships  should  be  capable  of  being  accessed  by  using 
the   Nationality    or    Ship  Class  elemants. 

f.      Engagement  Da*a    Base 

This  data  base  will  be  utilized  in  conjunction 
with  the  Track  Data  Ease.  Since  there  will  be  a  need  for 
information  in  both  data  bases  to  be  identified  by  a  track 
number,  it  appears  appropriate  to  store  both  data  bases  as 
one.  However,  each  data  base's  manager  will  only  have 
access      to    a     portion     of  the      information.  To    allow      for 

engagement  of  up  to  20  tracks,  an  array  of  20  elements  will 
be   needed.  Each    of  the  array      elements   will  consist      of  a 

record   with    sixteen    fields. 


Track   Number 
Type   Track 


Type   Engagement 
Class  of   Vessel 

Bearing 


integer   range    100, .3199 
integer   range    1..7 

(1=Surface   Friendly) 

(2=Air  Friendly) 

(3=Subsurface   Friendly) 

(4=surface   Hostile) 

(5=Air   Hostile) 

(6=Sub3urf ace   Hostile) 

(7=0nknown) 
integer   range   0..1 

(0=Manual ,1=Auto) 
integer   0. . 1 

(0=Large,  1  =  3mall) 
integer   range   0 . 359 (degrees 
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Range 
Latitude 


integer   range   0. , maxrange  (miles 
record 


Longitude 


Degrees 

Minutes 
Seconds 
record 

Degrees 

Minutes 
Seconds 


integer   range 
-90. .90 
integer   range    0..60 
integer   range   0..60 

integer   range 

-180. .  180 
integer   range    0..60 
integer    range    0..60 


Course 

Speed 

Number   Miss  Fire 

Firing   Sacuence 

Type    Missile 

Plight   Path 

Wa  ypoints 

Missile   Selected 

4.      Level    1    Modules 


integer   range   0. . 359  (degrees 

integer    range   0  ..  max  (knots 

integer   range    0..8 

array   range    0. . max 

integer   range    1. . 4 

TBD 

TBD 

integer   range    1..max 


Level  1  is  the  highest  level  in  the  simulation.  It 
corresDonds  to  the  Control  Module  of  Figure  2.1.  It  is  this 
module  which  will  be  responsible  for  controlling  all  lower 
level  modules  and  ensuring  that  the  simulation  always 
remains  in  a  consistent  state.  Immediately  upon  activation 
of  the  system,  the  Control  Module  will  be  responsible  for 
initializing  all  of  the  data  bases  with  their  reguired 
default  values.  This  may  require  the  addition  of  a  module 
to  perform  initialization  and  to  input  default  values  as  the 
coerator  makes  additions,  deletions  and  changes  to  appro- 
priate   cata    bases. 
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The  Conrrol  Module  will  also  be  responsibla  for 
ensuring  that  sufficient  parameters  are  available  when 
calling  lower  level  procedures.  It  will  be  at  this  level 
that  lower  level  modules  requiring  a  "time"  field  for  their 
data  structures  will  obtain  the  correct  -^.ime.  This  need  for 
a  "-ime"    field   will   be  addressed    in   the    next   chapter. 

The  simulation  must  further  meet  the  specifications 
of  AiDpendix  1  ,  requiring  a  training  mode  and  data  extract 
capabili-ny.  These  features  should  be  incorporated  to  allow 
the  user  to  specify  a  training  or  a  full  simulation  mode.  If 
the  training  mode  is  selected  then  a  file  in  secondary 
storage  will  be  opened.  Whenever  any  change  is  made  in  any 
data  base,  the  change  will  te  entered  sequentially,  wi-h  the 
time  of  the  change  in  the  secondary  storage  file.  This  will 
allow  for  later  retrieval  of  the  data  so  the  operator  may 
study   and  evaluate    his  training   session. 

5.      Lfl^l   2    Modules 

There  are  two  modules  at  this  level:  the  Process 
Module        and  the        Display  Module.  Normally  the 

Launcher/Missile  Assignment  Moduls  would  b'e  at  this  level, 
however,  it  has  been  moved  to  level  3  to  allow  for  manual 
input  of  launcher  and  missile  assignment.  This  will  permit 
the  operator  to  fire  a  missile  quickly  should  the  tactical 
situation  dictate,  without  having  the  engagement  analyzsd. 
This  does  not  prevent  automatic  engagement  which  may  also  be 
dependent  upon  time  constraints  and/or  the  tactical 
situation. 

a.      Process    Module 

The  Process  Module  will  control  the  selec-icn  of 
lower  level  modules  for  addition,  deletion  and  making 
changes  in  appropriate  data  base  records.  The  only  informa- 
tion   which   the      Process    Module   should   return      to    the  Conrrol 
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Module  is  information  concerning  srrors  in  improper  param- 
eter passing  and  records  not  found  error  messages.  If  the 
operator  selected  the  training  mode  a-  the  Control  Mcdul« 
level,  the  Process  Module  should  have  been  passed  this 
information  just  one  time.  This  will  allow  all  changes, 
additions  and  deletions  to  be  written  to  a  secondary  storage 
file.  Farther,  if  the  information  is  passed  just  once,  then 
valuable  time  will  not  be  wasted  at  each  call  to  the  Process 
Module  to  see  which  simulation  mode  has  been  selected.  The 
Process  Module  should  also  prevent  unauthorized  changes  in 
the  Threat  Data  Base  Manager  Module.  The  latter  requirement 
may  not  te  needed,  as  will  be  addressed  later.  The  Process 
Module  will  carry  the  added  burden  of  simulating  ship 
sensors,  NTDS  and  third  party  information.  These  tasks 
should,    if    possible,    be   conducted  concurrently. 

b.      Display    Module 

Here  is  the  module  that  has  the  potential  to 
become  v^ry  large.  The  Display  module  must  display  all 
requested  information  without  destroying  any  data  in  any  of 
the  data  bases.  This  module  should  only  pass  information  to 
the  control  module  concerning  errors  in  requests  for 
displays  that  do  not  exist.  This  module  will  undoubtedly 
require  additional  refinement  when  the  model  progresses  to 
the    model   enters  the   testing  phase  of   the   model   simulation. 

6»      IffYSi  1    Modules 

Most  of  the  data  base  managers  occur  at  this  level, 
with  the  exception  of  the  Plan  Engagement  Data  Base  Manager. 
The  majority  of  the  graphics  display  modules  are  also  at 
this  level.  It  is  here  that  extreme  care  must  be  made  in 
granting  write  access  to  the  data  bases  and  ensuring  that 
changes  tc  fields  in  the  data  bases  are  within  appropriate 
ranges.      This  might    be  accomplished   as   an    input   control. 
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a.  Ship   Parameter    Data   Base    Manager 

This  is  the  only  module  which  will  have  write 
access  to  the  Ship  Parameter  Data  Base.  After  initializa- 
tion cf  the  data  base,  the  operator  will  be  able  to  change 
the  fields  manually .  Automa-ic  updates  may  be  made  through 
the  Ccntrcl  Module  ficm  own  ship  sensors  (e.g.,  gyro,  navi- 
gation equipment) .  The  Control  Module  will  ensure  -hat 
ucdated  information  is  passed  to  this  module  as  required, 
and   upon    every      speed   or  course  change.  During    the   period 

between  updates  ordered  by  the  Control  Module,  the  Ship 
Parameter  Data  Base  Manager  will  cause  updates  every  minute 
based  uccn  current  course,  speed  and  position  in  the  data 
base.  This  will  permit  those  modules  with  read  access  to 
the  data  base  to  have  reasonable  confidence  in  the  accuracy 
of  the  data.  If  the  Control  Module  was  unable  to  obtain  an 
uodate  frcn  own  ship  sensors,  the  operator  will  be  notified 
that  the  data  may  be  out  of  time  tolerance.  This  light  be 
accomplished  by  prompting  the  operator  for  input  at  the 
required   time,    and    notifying   him   what   equipment   has    failed. 

b.  Environmental   Data    Base   Manager 

This  module  is  responsible  for  updating  the 
Environmental  Data  Base.  It  is  the  only  module  with  write 
capability  to  this  data  base.  Since  most  of  the  data  in  the 
Environmental  Data  Ease  will  remain  accurate  for  several 
hours,  with  the  exception  of  wind  speed  and  direction,  there 
is  no  mandatory  updates  unless  specified  by  the  operator. 
In  the  case  of  mandatory  updates,  the  operator  may  specify 
time  intervals  in  the  Control  Module,  to  permit  checking  of 
ship    sensors  for   wind  speed    and   direction   only. 
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c.  Convert    Ccordinates   Moduia 

This  module  will  provide  a  capabili-^y  for  the 
Track  Data  Base  to  be  updated  either  manually,  from  own  ship 
sensors,  or  via  the  NTDS  link.  As  this  module  receives 
information,  it  will  determine  tha  coordinate  system  repre- 
sented by  the  data.  The  Convert  Coordinates  Module  will 
then  change,  if  necessary,  this  daxa  to  coordinates  in  the 
r*»ference  system  the  operator  has  selected  (i.e.,  true,  NTDS 
grid,  qecqraphic).  If  this  module  has  been  accessed  solely 
to  add  or  delete  information,  then  no  conversion  should  take 
place.  at  any  point,  if  the  operator  chooses  to  change  the 
reference  system,  this  module  will  make  the  appropriate 
conversion   cf  data    for  the    display. 

d.  Threat    Data   Base   Manager 

The  Threat  Data  Ease  Manager  will  be  used  to 
change  data  in  the  Threat  Data  Base.  It  is  the  only  module 
that  will  have  write  access  to  this  data  base.  If  a  change 
is  made  tc  this  data  base,  it  should  be  don^  prior  to 
commencing  training  or  at  times  when  the  system  is  solely 
activated  for  this  purpose .  The  major  reason  for  this  is 
the  Do-centially  large  size  requires  that,  it  be  stored  in 
secondary  storage,  thus  significant  time  will  be  required  to 
access  the  desired  data  to  make  changes.  For  the  purposes 
of  this  simulation,  this  model  can  most  probably  be  deleted. 
The  reascn  for  this  is  that  since  only  twenty  keys  are 
required  to  be  under  software  control,  the  real  system  will 
probably  be  updated  off  line.  This  should  not  detract  from 
the  overall  testing  cf  the  system  in  later  phases.  It  is 
anticipated  that  secondary  storage  will  be  either  a  hard 
disc    or   bubble    memory. 
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€.      Menu  Display   Module 

This  module  will  selact  the  appropriate  menu 
from  the  Menu/State  Data  Base  and  display  it  on  the  screen. 
The  Menu  Display  Module  will  always  keep  track  of  the 
current  state  of  the  system,  and  only  display  rhe  available 
alternatives.  No  alternatives  should  be  made  available  that 
can  net  be  carried  cut  (e.g.,  allowing  a  change  to  the 
Environmental  Data  Base  when  the  Ship  Parameter  Data  Base  is 
currently  accessed)  .  All  menus  should  have  the  capability 
of   escaping     to    the      Main   menu.  This   feature      will   always 

allow  the  operator  to  escape  in  order  to  fira  a  missile. 
Since  this  allows  the  operator  to  escape  before  all  neces- 
sary data  might  be  input,  there  will  be  times  when  changes 
to  data  bases  should  not  be  made  until  all  the  reguired 
information  has  been  entered.  An  example  is  adding  a  track 
and  assigning  a  missile  without  providing  some  information 
concerning  range  and/cr  bearing.  In  this  case,  no  track 
should  be  added  until  minimal  information  has  been  provided. 
The  only  information  that  must  be  passed  to  this  module  is 
the  current  state.  Since  the  specifications  only  call  for 
20  keys  tc  be  under  software  control,  many  of  the  keys  will 
be  reguired  to  have  multiple  menu  assignments.  The  key  will 
therefore  have  to  be  displayed  with  the  menu  selection  to 
which   it   pertains. 

f.      Launcher    Missile  Status    Display  Module 

Here  the  operator  is  provided  with  the  ability 
to  check  the  current  missile/launcher  status  for  the  entire 
system,  or  any  portion  thereof.  The  Launcher  Missile  Status 
Data  Ease  may  be  read  by  this  module,  but  may  not  make  any 
changes  to  it.  If  the  operator  desires,  he  may  select 
display  for  a  particular  missile,  all  missiles  in  a  specific 
launcher,   or  for   the   status    of   all  missiles. 
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g.      Environmental   Display   .lod-ile 

When  called  by  the  Display  Module,  the  current 
values  for  the  environmental  conditions  from  the 
Environmental  Data  Base  will  be  displayed.  This  module  will 
only  have  read  capabilities  on  the  data  base.  However,  -he 
Goerator  will  be  able  to  select  from  one  of  the  lenus  to 
make    a   change. 

h.      Engagement   Display   Module 

The  EngagemenT:  Display  Module  controls  several 
lower  level  modules.  It's  main  purpose  is  to  decide  which 
module  re  select  based  upon  the  operators  desires.  Ir  will 
cause  information  from  the  Threat  Data  Base- to  be  displayed, 
or    infcrmation   about     the  current   engagement    plan.  If   the 

operator  selected  the  manual  engagement  display,  he  will 
have  the  opportunity  to  input  his  own  engagement  plan  and 
see  what  will  happen,  prior  to  any  changes  being  entered  in 
the  data  base.  This  will  present  the  operator  an  opportu- 
nity   to   check  his   plan  before    instituting   it. 

i.      Ship   Parameter    Display   Module 

This  module  will  display  all  information 
currently  in  the  Ship  Parameter  Data  Base.  It  will  only  be 
able  tc  read  from  the  data  base,  and  present  the  information 
in  an  intelligible  form  for  the  operator  to  understand.  A 
menu  selection  will  be  available  when  this  module  is  called, 
to   oermit      the    operator     to    institute   a      change  to      the  data 


base. 


Track  Display   Module 


This     is    the      last      module      at   level      3.  It's 

puroose    is   to  display  all  tracks    currently    in  the   Track   Data 
Base.         Ary   time  any   change    is      made    in    the  Track   Data   Base, 
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the    disolay     should   reflect      the   change.  This    inf crma- ion 

should      fce    displayed     at   all      times   for      the   operator.  To 

facilitate  this,  all  menu  displays  and  other  information 
must  be  displayed  on  areas  of  the  scraen  outside  the  track 
disolay.  The    one      exception      to     this  is      the      engagement 

disDla^    which   must    be  superimposed  on    the   track   display. 

7.      L§Y§1  1    Modules 

This  level  of  modules  controls  the  type  of  track 
uodate,  manual  missile  assignment,  automatic  and  manual 
enqaqement  planning,  and  the  display  of  the  engagement  plan. 
These  tt'Odules  will  be  used  almost  extensively  for  selecting 
lower    level   modules    to  process    data. 

a.      Type  Track  Module 

Little  is  required  of  this  module.  It  must 
decide  if  a  track  is  being  accessed  for  addition,  deletion 
or  update,  and  then  select  the  proper  lower  level  module. 
One  task  that  might  te  useful  to  incorporate  at  this  level, 
is  -o  maintain  a  count  of  the  number  of  active  tracks  in  the 
Engagement  Data  Base.  By  keeping  a  count  at  this  level, 
unnecessary  searching  of  the  data  base  can  be  prevented  when 
a   track    addition   is    needed    and  the  data    base   is    full. 

t.      Launcher    Missile    Assignment   Module 

This  module  is  one  of  the  most  significant. 
It's  purpose  is  to  allow  the  operator  to  bypass  engagement 
planning  modules  and  quickly  select  and  launch  the  desired 
missiles.  The  operator  will  have  the  option  of  assigning 
any      missile     to     a      specific        track.  After      launch     the 

Engagement  Data  Base  must  be  updated.  This  may  be  done  by 
uodatinq  the  Launcher  Missile  Status  Data  Base  with  informa- 
tion that  the  cannister  is  now  empty  after  the  missile  has 
teen    fired.  A    drawback      to   this  is      that   by     allowing  the 
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ooeratcr  to  fire  in  this  manner,  h?  will  not  be  able  to 
obtain  an  engagement  display  for  this  firing.  The  operator 
may    select   this    module  only    from   the    main   menu. 

c.  Plan   Engagement    Module 

This  module  automatically  generates  the  optimum 
type  enaagement  for  all  designated  tracks  unless  manual 
input  has  been  specified.  The  Launcher  and  Missile 
Assignment  Module  may  also  bypass  this  module  whenever  rapid 
firing  of  a  missile  is  mandated.  Information  will  be 
obtained  from  the  Engagement  Data  Module  and  Probabili-^y  of 
Acquisition  Module,  and  a  solution  identified.  The  solution 
will  then  be  entered  in  the  Engagement  Plan  Data  Base.  This 
information  may  be  displayed  by  the  operator,  whenever  he 
de  si  r  es . 

d.  Threat    Display    Module 

0?on  entry  into  this  module,  the  operator  will 
be  crompted  for  the  method  by  which  desired  information 
should  be  obtained  from  the  Threat  Data  Base  (i.e.,  via  ship 
name,  nationality,  or  ship  class).  After  the  operator  has 
made  his  selection,  the  module  will  access  the  Threat  Data 
Ease  in  secondary  storage,  and  display  the  reguested  infor- 
mation. The  operator  will  have  the  opportunity  of 
requesting  additional  information  if  he  originally  requested 
information  by  nationality  or  ship  class.  If  the  information 
requested  will  net  fit  on  the  screen,  the  operator  should  be 
able  to  conduct  paging  until  he  obtains  the  necessary  infor- 
mation. He  must  be  allowed  the  opportunity  to  escape  at  any 
time.  The  menu  selection  should  therefore  allow  for  paging 
until  all  the  information  has  been  displayed,  or  the  oper- 
ator   has   requested  ar  escape. 
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e.      Aatomatic   Engagement    Display    Module 

Here,  all  information  concerning  the  planned 
engaqemant  for  a  desired  track  is  displayed.  This  will 
allow  the  operator  to  see  before  hand  if  rhe  type  engagement 
is  proper,  and  if  not,  make  the  appropriate  adjustmenxs. 
Information  obtained  from  the  Engagement  Plan  Data  Base  will 
be  passad  to  a  Graphics  Display  module  so  that  the  aczual 
disDlay  m?y  be  made.  The  reason  for  passing  the  informa- 
tion, ins-ead  of  displaying  it  immediately  is  that  the 
Manual  Engagement  Display  Module  will  use  the  same  graphics 
module.      The  will  help  prevent   a   duplication   of   code. 

8»      1§Y?1   5    Modules 

This  level  might  be  considered  the  work  level.  It  is 
hare  that  the  majority  of  data  is  added,  deleted  or  changed. 
Information  is  also  obtained  at  this  level  for  forming  an 
automatic  engagement  solution.  The  Graphics  Display  Module 
also  does  all  of  the  work  at  this  level  to  present  the  oper- 
ator   with   an  engagement    display. 

a.      Delete    Module 

For  ease  in  deleting  a  track,  the  delete  mcdule 
will  locate  the  desired  track  in  the  Track  Data  Base  and  set 
the  Track  Number  and  Track  Type  fields  to  zero.  This  will 
cause   the      record   to     become   free   for      future   use.  If  the 

track  is  not  located,  the  operator  must  be  notified,  in  the 
event  that  an  improper  entry  was  made.  There  is  no  need  to 
zero  all  the  fields  in  the  data  base,  since  other  modules 
with  read  access  will  know  by  the  Type  Track  field,  that  the 
record   is   inactive. 
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t.      Update   Track   Module 

Here  the  operator  must  be  given  a  menu  selscricn 
to  oermit  this  module  to  decide  if  hs  wants  to  update  course 
and  spead  and/or  range  and/or  bearing.  He  should  have  the 
capability  of  update  any  or  all.  Hs  must  then  identify  the 
track  he  desires  to  updaxe.  If  the  update  is  automatic,  the 
Oz-date  Track  Module  will  decide  which  lower  level  module  to 
call. 

c.  Add    Track   Module 

If  the  add  Track  Module  is  called,  it  will 
search  the  Track  Data  Base  for  the  an  available  Track  Number 
field  to  have  all  zeros.  Zeros  in  the  Track  Number  field 
indicated  the  record  is  free  for  usa.  All  information  passed 
will  this  be  placed  in  this  record.  If  no  record  is  avail- 
able, the  operator  will  be  notified,  that  the  data  base  is 
full.  An  additional  requirement  for  the  track  data  base, 
may  be  the  need  to  place  a  priority  on  each  of  the  tracks. 
This  would  allow  the  removal  cf  th=  lowest  priority  track  if 
the  data  base  is  full  and  a  higher  priority  track  is 
designated. 

d.  Engagement   Plan    Data   Base   Manager   Module 

The  only  purpose  for  this  module  is  to  enter 
information  into  the  Engagement  Plan  Data  Base  as  specified 
bv  the  Plan  Engagement  Module.  It  is  the  only  module  to 
have  write  access  to  the  Engagement  Plan  Data  Base.  If  the 
operator  had  decided  en  a  manual  type  engagi^ment  of  his  own 
while  in  the  Manual  Engagement  Module,  this  information 
would  have  been  passed  up  and  down  through  the  Control 
Module. 
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€.      Probability   of    Acquisition    Module 

This  module  will  generate  the  probability  of 
acquisition  by  obtaining  information  from  the  Uncertair.ity 
Ellipse    Koduls.  Information   that    must      be   passed      to   this 

module   is   type    missile,      search      pattern,      type   target,      and 
target   ECU   capabilities. 

f.      Graphics   Display   Module 

This  module  will  probably  be  the  most  difficult 
and  cumbersome  module  to  develop.  It  must  be  set  up  to 
dis:-lav  all  the  information  concerning  engagement  of  all 
targets.  It  must  not  erase  the  information  displayed  by  the 
Track  Display  Module,  and  it  must  be  flexible  enough  to 
handle  use  from  the  Automatic  Engagamsnt  Display  Module  and 
the    Manual    Engagement   Display    Module. 

9.      Level  6    Modules 

This  is  the  lowest  of  the  module  levels.  At  this 
lev3l  minor  calculations  are  made,  data  is  obtained  from 
several    data  bases,    or  changes  are   made    in    data   bases. 

a.      Course/Speed   Update    Module 

If  called  by  the  Update  Track  Module,  the  Track 
Eaza  Base  will  be  accessed  for  a  course  and/or  speed  change. 
This  module  must  ensure  that  all  entries  to  course  and/or 
soeed  are  within  proper  range.  If  not  the  operator  must  be 
notified  to  reenter,  or  verify  the  the  information  to  be 
correct.  If  the  change  was  requested  by  an  automatic  update, 
and  was  out  of  range,  the  information  must  be  displayed  to 
the  operator,  so  that  corrections  may  be  made  or  the  request 
canceled. 
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b.  Bearing/Eange  Opdats   Moduls 

This  module  will  operate  in  the  3am=»  manner  as 
the  Update  Track  Module,  except  it  will  only  deal  wirh  the 
bearing    and/or    range    parameters. 

c.  Launcher    and   Missile   Status    Module 

The  Launcher  Assignment  Module  may  obtain  infcr- 
mation  directly  from  this  module  in  order  to  select  an 
available  missile  for  immediate  firing.  This  module  will 
access  the  Launcher  Missile  Data  Base  and  permit  the  oper- 
ator to  select  any  missile  net  inhibited  for  launch.  Once 
the  missile  is  fired  an  update  must  be  made  through  the  Plan 
Engagement  Module  in  the  event  that  the  missile  has  been 
selected  for  another  target  in  the  Engagement  Plan  Data 
Ease. 

d.  Threat    Data   Module 

The  only  function  of  this  module  is  to  read  data 
from  the  Threat  Data  Base,  and  provide  the  information  to 
the  Engagement  Data  Module.  The  module  does  not  have  write 
capability    for    the    Engagement    Data  Base. 

€.      Oncertainity   Ellipse    Module 

By  taking  parameters  such  as  number  of  missiles 
to  be  fired,  probability  of  acquisition  of  the  target,  and 
lethal  capability  of  the  missile  (s)  being  fired,  this  module 
will  return  ellipses  to  determine  the  uncertainity  of 
locating  the  target  within  each  ellipse.  This  information 
will  fce  provided  up  the  line  to  the  Plan  Engagement  Module 
for   evaluation. 
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B.       SIUaiATIOH    0VEH7I1W 

Sines  the  objectives  of  each  module  in  the  simulation 
has  been  €stablishe(3,  an  overview  of  how  the  simula-cion 
should  interact  with  the  user  is  in  order.  This  overview  is 
net  all  encompassing,  and  should  not  rastrict  implementation 
on  a  broader  or  more  conservative  scale.  Specifications  set 
forth  in  Appendix  C  should,  however,  be  maintained  as 
closely   as   possible. 

Immediately  upon  activation  of  the  simulation,  all  data 
bases  will  be  initialized  to  their  default  values.  The  user 
should  not  be  required  to  provide  any  input  to  effect  this 
initialization,  with  the  possible  exception  of  specifying 
the  tyce  clatform  (e.g.,  destroyer,  frigate,  cruiser).  The 
exception  could  be  randomly  generated  to  keep  the  user  from 
always   using  the   same  type    platform. 

After  initialization  has  been  completed,  the  user  will 
be  crcmpted  for  his  desired  mode  of  simulation:  full  simula- 
tion mode  or  training  mode.  The  only  difference,  in  the 
selections  is  that  the  latter  causes  all  changes  to  any  data 
base  to  be  entered  in  a  secondary  storage  file  for  larer 
purusal.  The  user  will  then  be  prompted  for  the  current 
time  in  hours,  minutes  and  seconds.  This  information  will  be 
used  to  start  a  real  time  clock.  The  clock  will  time  the 
simulation,  and  provide  random  variants  for  the  generation 
of  shio  sensor,  automatic  input  and  required  manual  input 
data.  This  latter      feature      will      provide   some      sens*     of 

realism  by  requiring  some  information  to  be  manually  input 
by  the  user.  Further,  the  use  of  theoretical  frequency  or  a 
probability  distribution  is  considered  to  be  more  efficient 
use  of  computer  time  and  memory  storage  requirements  than  a 
canned   table  look-up    procedure. 
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Throughout  the  simulation,  -he  user  will  be  randciily 
provided  wixh  information  concerning  all  of  the  data  bas^s. 
He  should  have  the  option  to  decide  ax.  any  time  to  input 
additional  information,  provided  the  input  makes  sense. 
Additionally,  provisions  should  be  provided  to  simulate  xhe 
failure  cf  some  of  the  ship  sensors,  but  not  sufficient 
enough   -o      stop    the    simulation.  An   example      is    simulating 

NTDS  link  failure,  but  then  providing  data  for  manual  input. 
One  final  intsractive  feature  that  should  be  provided,  is 
not  allowing  automatic  update  to  the  information  the  user  is 
manually  updating,  as  opposed  to  information  simply  being 
accessed.  The     simulation      will     terminate     whenever      all 

missiles  have  been  fired,  or  only  unlaunchable  missiles 
remain.  The  user  may  also  terminate  the  simulation  at  any 
time . 

One  additional  feature  that  might  be  advisable  -^.o  add  is 
a  "freeze  problem"  feature.  This  would  allow  the  simulation 
to  be  stopped  during  the  training  mode,  to  allow  the  cper- 
axor  to  evaluate  the  problem.  The  operator  could  then  resume 
the    simulation    at  the  same    point    that    it    was   stopped. 
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IV.     SYSTEM   DESIGN    LiNGOAGE    S ELECT lOH 

an  important  step  in  the  model  simulation  is  the  selec- 
tion of  a  system  design  language.  It's  purpose  should  be  to 
show  what  program  units  are  needed,  and  what  interfaces  each 
unit  reouires.  However,  by  selscting  a  system  design 
language,  no  restriction  is  placed  on  selecting  an  alterna- 
tive   programming  language   for   actual    implementation. 

a.       SEIECTICH  GOALS 

In  selecting  a  system  design  language,  no  assumptions 
have  been  made  about  the  type  of  computer  that  will  be 
selected      for      i iple mentation.  For   the      purpose      of      this 

thesis,  the  selection  of  a  system  design  language  will  be 
tased  upon  several  necessary  qualities  for  practical  soft- 
ware engireering.  The  primary  goal  of  the  design  is  that 
the  solution  meet  the  stated  specifications.  This  goal  is 
rarely  m€t  if  the  fcllowing  software  design  qualities  are 
not  achieved;  modif lability,  efficiency,  reliability  and 
understandabilit y.  The  achievement  of  these  qualities  will 
enhance  tte  attainment  of  a  good  simulation  model  as  speci- 
fied   in    Chapter    1. 

!•      Mcdifiabilit^ 

Although  difficult  to  realize,  the  ability  to  easily 
modify  the  the  software  is  vitally  important,  because  at 
some  point  a  change  in  the  specifications  will  become  neces- 
sary. To  effectively  change  a  system,  the  current  design 
and  code  structure  must  be  maintainsd.  If  the  structure  is 
maintained  by  "patching",  for  example,  further  modification 
effort        rises      exponentially        to     nightmare        proportions. 
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Therefore,  the  selection  of  a  design  language  should  p=rniit 
the  introduction  of  changes  wi-hout  increasing  the 
comolexity    cf  tha   original    structure. 

Several  principles  directly  support  the  attainment 
of  this  quality.  The  first  is  abstraction.  By  reducing  the 
number  of  details  a  designer  is  required  to  know  and  under- 
stand, at  any  particular  point  in  the  design,  the  system 
becomes  more  structured  and  understandable  and  thus  mere 
maintainable.  When  a  structured  system  has  been  developed 
utilizing  modules  which  are  independent  of  each  other,  modi- 
fications should  not  radically  change  the  overall  structure 
of    the    system. 

Another  principle  which  works  in  conjunction  with 
modularity  is,  localization.  If  modules  are  created  with 
loose  interconnections  and  cohesiva  internal  elements,  then 
the  effects  of  modification  can  be  limited  to  a  selec*  set 
cf   modules. 

Two  other  principles  also  support  modif iability; 
completeness  and  ccnf irmability.  When  both  are  used 
together,  the  system  may  be  easily  decomposed,  and  therefore 
become    aasily   modifiable. 

2-      Eff  iciencY 

Efficiency  evokes  the  premise  that  all  available 
resources  will  be  utilized  optimally.  In  the  software  sense, 
these  resources  may  be  distributed  between  time  and  space. 
Eoth  are  obviously  somewhat  dependant  upon  the  underlying 
hardware.  Tha  final  design,  in  this  case,  must  be  amenable 
to  real  tim*  events,  in  order  to  allow  some  sense  of  realism 
when  compared  to  the  actual  system.  For  the  actual  design 
of  this  simulation,  space  resources  should  not  impose  diffi- 
culties since  implementation  is  to  be  made  on  a  large 
comcuter   system. 
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The  principles  which  most  closely  support  this 
quality  include  completeness  and  conf irmability. 

Completeness  ensures  xhat  all  important  elements  are 
present,  permitting  fine-tuning  of  a  low-level  implementa- 
tion without  affecting  higher  level  modules.  Conf irmability 
then  allows  for  testing  the  "improvements"  of  this  find- 
tuning,  to  ensure  that  the  system  actually  achieves  the 
stated   goals  of   the    specifications. 

3  •      ??ii§^ilitY 

Reliability  is  a  crucial  quality  for  the  HWS  system. 
It  is  not  a  quality  which  can  be  built  in  after  design  is 
accomplished;  it  must  be  instituted  from  the  beginning.  In 
the  case  of  the  simulation  model,  if  a  failure  occurs, 
degradation  should  occur  gracefully,  and  net  allow  fatal 
side  effects.  If  monitoring  of  simulated  ship  sensors  is 
talcing  place  automatically,  the  loss  of  one  sensor  should 
not  necessarily  cause  the  simulation  to  fail.  In  this  case, 
manual  inputs  could  be  encouraged  through  exception 
handling. 

All  of  the  principles  already  discussed  which 
suDccrt  modif lability  and  efficiency  also  apply  to  reli- 
ability, but  for  somewhat  different  reasons.  By  applying 
abstraction,  and  the  additional  principle  of  information 
hiding,  cnly  logical  operations  may  be  accomplished  at  any 
particular  level.  Similarly,  if  modularity  and  localization 
have  been  applied  in  some  purposeful  manner,  then  there  will 
be  limited  interface  between  the  systems  modules,  further 
enhancing  reliability  through   reduced   complexity. 

a .      Onderstandability 

In  producing  the  model  translation,  understand- 
ability  is  probably  one  of  the  most  desirable  qualities.  It 
serves   in   managing   the  intricacies     of    software   systems,      by 
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acting  as  a  interlink  berween  a  problem  definition  and  an 
appropriate  solution.  Un derstandability  is,  therefore, 
fundamental  to  the  other  qualities  of  modif lability ,  effi- 
ciency  and   reliability. 

Every  principle  discussed  thus  far  also  supports 
understandability.  Abstraction  extracts  essential  details, 
while  infcrnaticn  hiding  suppresses  how  rhey  are  imple- 
mented. Modularity  and  localization  then  places  these 
details  into  some  well  structured  design.  Then  with  another 
principle  of  uniformity,  all  similar  structures  will  be  of 
the      same      logical      design.  Then      with      completeness      and 

confirmatility ,  all  the  necessary  information  will  be 
present   to    understand  the  system. 

B.       ADA    OVEBVIEH 

Before  specifying  Ada  as  the  model  design  language,  an 
overview  of  the  language  is  needed  to  see  if  it  will  meet 
the  selection  criteria.  Part  of  the  criteria  set  forth  by 
the  Ada  designers  was,  program  maintainability,  program 
reliability,  efficiency,  and  consideration  of  programming  as 
a  human  acrivity.  If,  in  fact,  these  criteria  have  been 
achieved,  then  at  least  on  the  surface,  the  design  criteria 
has  already  been  met.  However,  a  quick  lock  at  the  structure 
of   an    Ada   program  might   prove   to    be   a    better    indicator. 

Ada  is  an  extremely  large  language.  It's  purpose  is  to 
be  able  to  respond  to  important  programming  issues  in  prac- 
tical, real  world  systems.  To  facilitate  ease  of  use,  an  Ada 
program  consists  of  cne  or  more  units,  where  each  unit  can 
be  coaT3il€d  separately.  To  abstract  further,  each  unit  may 
be  composed  of  any  combination  of  subprograms,  tasks  and 
packages. 
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1.  Subrro^rams 

Subprograms  in  Ada,  like  other  languages,  are  param- 
eterized units  of  programming.  It  may  be  a  procedure  or 
function,  and  it  defines  a  singls  action.  Functions  are 
utilized  as  components  of  an  expression,  and  ther*^fcre 
return  some  ras^ilt.  Procedures,  on  the  other  hand,  are 
called  by  statements,  and  return  no  results.  These  compo- 
nents seem  rsadily  relegated  to  performing  fairly  specific 
duties,  such  as  computing  the  Oncertainity  Ellipse  at  the 
lowest  level  of  the  simulation  model.  The  subprogram  unit 
readily  supports  the  principles  of  modularity,  abstrac-ion, 
localization  and  information  hiding. 

2.  Tasks 

The  task  defines  seme  action  that  is  logically 
executed  in  parallel  with  other  tasks.  It  can  be  visualized 
as  independent  but  concurrent  operations  of  program  units. 
This  would  therefore  allow  implementation  on  a  multipro- 
cesser,  a  single  processor,  or  a  network  of  processors. 
This  gives  Ada  the  added  attribute  of  flexibility.  With  the 
ability  tc  conduct  parallel  action,  the  task  structure  would 
be  quire  amenable  to  accessing  and  updating  dara  bases  in 
the  simulation  model,  and  for  obtaining  updates  from  simu- 
lated  ship   sensors. 

3.  Packages 

Packages  are  components  of  a  program  unit  which 
allow  for  encapsulation  of  other  components  which  are  Icgic- 
allv  related.  This  includes  data  rypes,  data  objects, 
subprograms,  tasks,  and  even  other  packages.  This  allows  for 
the  expression  and  enforcement  of  a  logical  abstraction. 
Packages  further  support  the  principle  of  information 
hiding.    Only  the   information  necessary   for  the  user  to 
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utilize   the    package    is  presented.  The    body   or    implemen-^a- 

tion    is    hidden       from    the   user   since      he    has   no  need      -o   know 
how   the    package    is    constructed. 

'^  •      ether   Ada   Features 

There  are  several  ether  irems  in  Ada  that  tend  to 
encourage  selection  of  Ada  as  the  simulation  model  design 
lanquage.  The  first  is  the  exception  handling  capability.  If 
an  error  (e.g.,  divide  by  zerc,  buffar  overflow)  or  failure 
(e.g.,  peripheral  fails),  processing  should  still  continue 
even  at  reducad  capability.  Ada  permits  user  defined  excep- 
tions, as  well  as  some  predefined  axception  conditions.  The 
exception  handler  would  be  id^al  for  describing  situations 
where   simulated    ships  sensors   simulate    failure  conditions. 

The  generic  program  unit  is  another  positive  feature 
for  selecting  Ada.  With  this  tool,  an  algorithm  can  be 
written  to  perform  tfce  same  operation,  but  on  different  data 
types.  This  feature  would  be  useful  for  describing  situ- 
ations wtere  single,  or  even  multiple,  fields  of  different 
data    bases   are    updated. 

Globally  assigned  variables  are  also  provided  by 
Ada.  This  would  be  useful  in  identifying  the  current  state, 
for  menu  display  purposes,  for  all  modules  in  the  program. 
However,  if  needed,  packages  could  localize  the  effects  of 
these  variables.  It  is  doubtful  zhat  many  global  variables 
would  be  needed  for  this  simulation,  but  the  option  is 
available.  However,  extensive  use  of  globally  assigned 
variables   is  considered   poor   programming   practice. 

A  final  feature  is  the  CLOCK  facility.  Most  program- 
ming languages  require  access  to  the  operating  system  to 
obtain  time  services,  but  Ada  has  provided  an  avenue  to 
obtain  tiire  information  without  defaulting  to  the  operating 
system.      Since    the    simulation   will  require   the  services   of  a 
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real    time   clock,      this  facility   weald      lead  to  a    more   ur.der- 
standabl€   simulation   design. 

C.        &D&    AS    THE    SYSTEM    DESIGN   Li^NGUAGE 

It  is  apparent  that  Ada  holds  all  those  qualities  needed 
in  designing  a  system.  Therefore,  Ada  is  recommended  as  ths 
system    design   language. 

Reference  3  established  a  structure  for  the  program 
design  as  depicted  in  Figure  4.1.  in  presenting  this  struc- 
tura ,  two  modifications  were  made.  First,  the  Launcher 
Missile  Status  was  moved  under  the  Update  Module,  to  accom- 
modate grouping  of  similar  tasks.  Secondly,  the  Threat 
Disolay  was  moved  up  one  level  for  rhe  same  reason.  The 
overall  structure  continues  to  remain  the  same  as  that  shown 
in   Figures    2.1    through  2.U. 

Appendix  F  presents  a  generalized,  top-down  type 
approach  in  converting  to  a  system  design  language.  It's 
purpose  is  to  give  a  rough  presentation  of  several  of  the 
structure  modules  of  figure  4.1.  Although  the  semantics  have 
not  been  checked,  the  syntax  has  been  verified.  This  layout 
should  assist  in  the  actual  conversion  from  ths  specifica- 
tions   to   the  system    design    language. 
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Figure  4.1   Program  Design  Structure. 
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7.     COWCipSIONS    AND    RECOMMENDATIONS 

In  developing  a  design  for  a  simulation  model,  i-  is 
often  easy  to  loose  track  of  the  original  problem.  This 
thesis  has  attempted  to  establish  a  design  to  validate  the 
soecifica'ricns  for  the  HSCLCS  update,  identify  problem  arsas 
and  necsssary  changes  to  these  specifications.  This  design 
should  ultimately  lead  to  a  verification  of  the  system 
requirements. 

Although  the  intended  purpose  of  the  simulation  is  not 
to  create  a  prototype  of  the  HSCLCS,  it  can  be  used  to 
develoD  such  a  protot.ype  and,  in  addition,  if  properly 
disignsd,  be  used  as  a  valuable  training  device.  This 
training  can  be  applied  as  a  method  of  providing  access  to 
the  type  cf  information  an  operator  can  expect  to  encounter, 
cr  crovide  a  reasonable  facsimile  of  a  real  time  HAEPCON 
engagement. 

In  developing  this  design,  several  items  appeared  to  be 
the  most  sianificant.  First  was  the  decision  as  to  whether 
the  ::rotl€m  could  best  be  solved  by  a  simulation.  Reference 
3  provided  an  analysis  to  help  make  this  decision  in  the 
affirmative.  Next,  was  the  issue  of  narrowing  down  the 
boundaries  cf  the  real  system  which  should  be  simulated.  As 
the  model  design  progresses,  the  need  to  modify  these  deci- 
sions will  undoubtedly  be  required.  This  will  entail 
removing  seme  items,  since  normally  most  designers  tend  to 
incorporate   too      much  vice      too   little.  This   design      will 

surely  support    this    conclusion. 

The  model  specification  was  another  important  issue  that 
this  thesis  had  to  resolve.  To  this  end,  several  concepts 
proved  themselves  invaluable.  The  first  was  abstraction. 
This   allowed     the  identification      of    those      features   of      the 
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r^al  system  which  were  essential  in  the  model.  Then,  by 
utilizina  the  concept  of  modularity,  each  primary  fas-.ure 
was  specified  independent  of  the  specifications  of  any 
ethers. 

A  final  idea  that  was  utilized  at  the  model  specifica- 
tion stace,  was  to  avcid  restricting  the  implementor.  If  the 
specif icaxion  contains  to  much  detail,  an  undue  burder  may 
te  olaced  on  the  actual  implementation.  This  can  produce  a 
modal  rhat  does  not  accurately  reflect  the  system  it  is 
intended   tc   represent. 

a.       RECOHHEHDED    FOLLCi-ON   WORK 

The  auxhor  recommends  exploring  the  following  areas  in 
further  support  of  the  HS CLCS  improvement  and  simulation 
medal    desigr  methodology: 

-  Research  and  develop  the  algorithm  for  the  uncertainity 
ellipse   to    support  the    HSCLCS   simulation   model. 

-  Research  and  develop  the  algorithm  for  the  probability 
of   acquisition   tc  support   the   HSCLCS    simulation   model. 

-  Develop  a  graphics  package  in  support  of  the  HSCLCS 
simulation    model. 

Investigate    different      computer  systems      for    implementa- 
tion  of   a  final    design. 

-  Convert  the  simulation  model  design  into  the  System 
Desian    language    using   Appendix   F    as    a   guide. 

-  Research  whether  of  aspects  in  this  simulation  which 
might  be  transferable  to  simulation  model  development  of 
other   cruise  missiles   and  their    follow-ons. 

-  Study  the  feasibility  of  utilizing  Ada  as  the  program 
design  language,  in  addition  to  the  system  design 
language,    for  the  HSCLCS   simulation   model. 
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APPENDIX    A 
GLOSSARY 

Data  Ease  -  A  file  of  interrelated  data  stored  together 
to  serve  ens  or  more  applications  and  that  remains  indepen- 
dent   cf    programs   using  the    data. 

Data  Structure  -  Dictates  "he  organization,  methods  of 
access,  degree  of  associativity  and  processing  alternatives 
for    information. 

Embedded  System  Pro gr a  m  -  A  computer  program  that  is 
part  cf  seme  larger  entity  and  essential  to  the  operations 
cf  that  system.  For  example,  the  timer  on  a  washing  machine 
or  the  guidance  system  in  a  missile  may  have  computer 
proqrams   which   are    considered   to   be   embedded. 

Function  -  Name  given  to  one  or  more  statements  that 
perform  a  specific  task.  Results  in  a  value  being  assigned 
to    its   name   upon  execution    cf   that  specific   function. 

Information  Hidin_g  -  Specification  and  design  of  modules 
so  that  infcrmation  (procedure  and  data)  contained  within  a 
module  are  inaccessible  to  other  modules  that  have  no  need 
to   know   the   information. 

Interface  -  Communications  between  modules  governed  by  a 
set   of   assumptions   one  module   makes   about   another. 

Module  -  A  seperately  addressable  element  with  a  single 
coherent    purpose. 

Modular  Dssi^  -  a  logical  partitioning  of  software  into 
elements   that  perform  specific   functions   or   subf unctions. 

Navy  Tactical  Data  System  -  A  communications  link 
between      different      platforms      (e.g.,  surface      ships      and 

aircraft,  submarines  and  surface  ships).  Real  time  informa- 
tion   is   passed    via   this   communication    link. 


56 


Package  -  A  prcgram  unit  spacifying  a  collection  of 
related  entities  such  as  constants,  variables,  types,  and 
subprograms.  The  visible  part  of  the  package  contains  the 
entities  that  may  be  used  from  outside  the  package.  The 
private  parx  of  the  package  contains  structural  details  that 
are  irrelevant  to  the  user  of  the  package  but  that  complete 
the  specification  of  the  visible  entities.  The  package  body 
contains  the  i up le mentation  of  the  subprograms  or  task 
(cossibly   other    packages)    specified   in   the    visible   part. 

Packaging  -  Alludes  to  the  techniques  used  to  assemble 
software  for  specific  processing  environmeni:  or  to  ship 
software   to    a  remote   location. 

Probability  of  Acquisition  -  Calculated  probability  of 
seek-h^ad  acquisition  of  intended  target  based  upon  informa- 
tion   available. 

Subordinate  Module  -  A  module  controlled  by  another 
module. 

Subprogram  -  An  executable  program  unit,  possibly  with 
parameters    for      communication   with     its   point      of    call.  A 

suborogram  declaration  specifies  the  name  of  the  subprogram 
and  its  parameters;  a  subprogram  body  specifies  its  execu- 
tion. A  subprogram  may  be  a  procedure,  which  perforins  an 
action,   or   a  function,   which   returns    a  result. 

Sysrem  -  A  collection  of  elements  related  in  a  way  that 
allows   accomplishment  of  some   tangible   objective. 

Task  -  A  program  unit  that  may  operate  in  parallel  with 
ether  program  units.  A  task  specification  establishes  -che 
name  of  the  task  and  the  names  and  parameters  of  its 
entries;  a  task  body  defines  its  execution.  A  task  type  is 
a  soecif ication  that  permits  the  subsequent  declaration  of 
any  number  of  similar  tasks.  A  task  is  said  to  depend  upon 
the  unit  in  which  it  is  declared  (subprogram  body,  task 
body,  or  a  library  package  body).  A  unit  is  not  left  until 
all    dependent  tasks   are   terminated.         A    task    is    completed   if 
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it   is    waiting  at   the    end   of    its    body    for    amy    dependent    tasks 
cr    is      atcrted    but      net   yet      terminated.         A     completed   task 


cannot   be   called 


A  terminated   task      is. 


a    s<zT.s' 


the 


same    as    a   dead    task    in  that    it   is  no    longer   active. 

Oncertainty  Ellipse  -  A  probability  associated  with  a 
track  (cr  target)  that  its  position  is  within  a  given 
geographical  location. 
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aPPENDIX    B 
iCBCHIHS   AND    ABBRBVI ATIOHS 

BIT  -    Built    In    Test 

BOL  -   Bearing    Cnly  Launch 

BRG  -    Bearing 

CML  -   Cannisrer  Missile   Launcher 

CPU  -   Central    Processing  Dni- 

ECU  -    Data   Conversion    Unit 

CPC  -   Data   Processor    Computer 

GDS  -   Graphics   Display   System 

HCC  -   HARPCON    Control    Console 

HSCLCS  -   HARPCON    Shipboard   Command-Launch   Control   Set 

HWS  -    HARPCON    Weapons   System 

NTDS  -    Naval  Tactical    Data   System 

OLS  -   On- Line -Sizing 

RAM  -   Random    Access  Hemory 

RBL  -   Range  and   Bearing   Launch 

ENSH  -   Royal   Navy  Sublaunched  HARPOON 

STOT  -   Simultaneous  Time-on-Target 

DV-EPROM  -   Oltra-Viclet    Eraseable   Programmable  Read-only 
Memory 

WCIP  -    Weapon   Control- Indicator    Panel 
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WCS  -    Weapons   Ccntrol    System 

ZULU  -   Greenwich   Mean    Time 
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aPPENDIX    c 
BSCLCS    EHGAGEMENT   PLAHNING/OPERATIOHAL    EHPLOYMEHT    PU8CTI0NS 

Cserational    Kit  a/In  formation  Requiremert 

Basalin9     Design   Goal 

1a.    Surface   Contact    Pcsition  10  20  (min) 

(ranqe/bearing)  . 
Th€   use   of    bearing  line    in 
addition  to    the    It   requirement 
reduces   the    number  of   displayed 
surface    contacts   by   two    per 
bearing   line. 
-Designated   Target  X 

Target   Category    and   Classifi- 
cation  Displayed. 
-Unintended   Target  (s)  X 

Target   Category    and  Classifi- 
cation   Displayed. 

lb.    Surface  Contact/Bearing    Line 

2.  Own    Ship  Position 

3.  Air   Contact    Position 

U.       3rd   Party  Targeting  Data   Source 

Designation 

WCIP   shall    rasolve  target    position 

based  on  range    and  bearing   input 

from    3rd  party    or  bearing    lines 

from   3rd  parties   or   own    ship. 
-Manual   Entry  of   Bearing    Lines  X 

-Manual    Entry  of    Bange  and   Bearing  X 

5.      Target   Classification 
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1 

3  (min) 

X 

1 

3 (min) 

2 

3 (min) 

-Larg€    (default)  X 

Larq«r   than    a   patrol    boat. 
-Small  X 

Patrol    boat    or    smaller.  A 

6.  Contact/Track  Course   Direction 
Indicator 

Program    automatically  compensates 

for   own   ship's    motion. 
-Direction  Indicator  X 

-Dead    Beckoning    (Cwn   Ship   Only)  X 

7.  Contact/Track  Targeting   Data    Source 
-Manual    Input  X 

With   appropriate    data  source    error; 

includes  3rd  party. 
-Automatic  Input 

-NTDS  X 

-BACflE  X 

-SONAR  X 

-EW/ESM  X 

-Target  Designation   System  X 

8.  Hind   Parameters     (relative) 
-Speed 

-Actual  X 

Manual  input. 
-Default  value  X 

-Direction 

-Actual  X 

Manual  input. 
-Default  value  X 

9.  Temperature 

-Actual  X 

Manual    input. 
-Default   value  X 
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10.  Precipitation 

-l€S  X 

Manual  input. 
-No  (default  value)  X 

11.  Oparatcr  Cues/Lockouts 

-Launch   Inhibited    (lockouts/cue)  X 

All   launch    inhibits   except   roll/ 
pitch   cuxout. 
-Missile   Ready    (cue)  X 

-Data    Ag«    (cue)  X 

Target    and    envircrmenta 1  data. 
-Missile   Launch    Status    (cue) 

-Cell/Rail    Empty    (missile   away)  X 

-Missile  Dud  Declaration  X 

-New   Contact/Track  to   be    Input    (cue)         X 

-Illegal    Action    (lockout /cue)  X 

12.  Time/Clock 

-ZDLD   Time  X 

Start    clock:    Autcmatic    entry    via 
NTDS   Interface    and/or   manual    entry. 

-Time   on   Target  X 

Manual   entry. 

-Time   of   Launch  X 

Computation. 

-Countdown  X 

Includes  Time-to-Fire  and 
Time- tc- Impact. 

13.  Loadout   Status/Missile    Variant 
Identification 

-Easeline/Block    I   Tactical    Missile  X 

(EGM-SUA) 
-Royal    Navy    Submarine   HARPOON  X 

(EGM-84E) 
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When   rscoafigured  for  surface 

launch. 
-Block   IE  Tactical   Missile  X 

(EGM-8UC) 
-Block   IC  Tactical   Missile  X 

(EGM-8UD) 
-Suoplemental  Identification  X 

(manual    entry:    info   from   loadoat 

Icgbocks  of    hybrid/nonstandard 

seeker-MGD   combinations). 
-Training  All-Op    Bound    (RTM-8UA/C/D  X 

and   RNSH) 

14.  Missile   In-Flight  Tracks  X 

15.  Op   tc    180   degree   Cff-Axis    Launch  X 

Oceraticnal   Selections 

1.  Reference  System 

-Trua   Target    Bearing/Relative    Target        X 

Range 

Top   cf    display    is  north. 
-NTDS   Grid  X 

-Geographic    (latitude    S    longitude)  X 

2.  Planned    Missile    Flight    Path  3 
Software  to    ensure  that    no   flight  WPS 
path   may  be    selected   which   could 

result   in  the  acguisition   of   own 
ship. 

3.  Search    Mode    Selection 

-On  Line   Sizing    (default)    w/Manual  X 

Override 

On   Line   Sizing    shall  be    automat- 
ically  selected    if  RBL    or    EOL   are 


64 


not   iSl<=cted, 
-Range   and  Bearing  Launch    (RBL)  X 

BBL   pattarn    size   shall    be      a 

function  of    total  flight   path 

(range   traveled   to  target) . 
-Bearirg   Only   Launch    (BOL)  X 

U.       Selectable    Search  Pattern   Expansion 

(0   -   360  degrees)  X 

Fcr   RGM-8aD    irissile    only,    applies 
to   RBL   mode    and    On-Line -Sizing 
(CLS)    which    results    in    an   RBL 
search   pattern. 
-Normal    Center   Expansion  X 

For    RGM-8UA/BGM-6UB/RGa-8aC 
missiles;   default   for   RGM-84D 
missile. 

5.  Enable   and    Destruct    Ranges    BOL  X 
Default    values    or   manual  entry 
(ranqes   not    supplied  over   NTDS 
interface)  . 

6.  High   Altitude  Hold 
RGM-8aD    only. 

-Nc   Entrv;    Default  X 

The    High  Altitude   Hold    default 
range   net  to  interfere    with   search 
initiation    and   not  to   exceed    lOnm; 
i.e..    High    Altitude   Hold   range  is 
set   to   the    minimum  of   1 0nm  or   range 
to   search  initiation. 

-Manual    Entry  X 

The   selected  High  Altitude   Hold 
range   must    be  less  than   the   range 
to   search   initiation. 
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7.  Pres€arch  Fly-Out 

-Sea    Skim    (RGM-84D  only)  X 

Default    mode  -    Presearch  Fly-Out    is 

set   to    sea    skim    altitude   following 

the   High  Altitude  Hold. 
-Manual    Entry  X 

Presearch  Fly-Out  at    normal   HARPOON 

run-in   altitude    as  used    in   current 

HSCLCS. 

8.  Terminal  Attack    Kode    (RGM-84D  only) 
-sea   Skim    (default)  X 
-Pop-up  X 

Default    override   ty   manual   selac- 
tion    cf    pop- up,     "SMALL    TARGET" 
designation    by    NTCS,    or    when 
"SMALL   TARGET"    is  entered    manually. 

9.  Missile    Assignment   for    Engagement 
Planning  X 
Manual   entry. 

10.  Mul-i-Missile  Engagement   cf  4  8 
Designated    Target. 

Baseline:   Up  to    4   missiles   from   a 

single    launcher.     (Note:     Single 

launcher  includes  TARTAR      and 

ASROC).    Design   Goal:    Up   to   8 

missiles  from   2    CML*s. 
-Salve    Missiles    Against    One   Target  X 

For    Simultaneous   Arrival    (STOT 

Salvo) . 

Operator-planned   engagement. 
-Salvo   Against   Up   to   Four   Targets  X 

(single   air  point)    From    One  Launcher 

For   Simultaneous   Arrival    (STOT 
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Salve)  . 

Sam«   aimpoint   and  a   different   RBL 
s€arch   expansion    for   each    RGM-8UD 
missile    in    order   to   distribute 
salvced   missiles   among    the   targets 
in   a   formation. 

-SipplG   Salvo  as    per  current   HSCLCS  X 

CHL   Configuration. 

-Quick  Reaction/Preprogrammed    STOT  X 

Salvo. 

Modified  HSCLCS    automatically   will 
calculate  and  enter   a   differen- 
wavpcint  for  each  RGM-84D   missile 
in   a   quick    reaction   salvo    for 
simultaneous  time-on-ta rget    (STOT). 

11.    Background    data    and   sector   data  X 

request. 
Usable   with    NTDS    interface  only. 

ENGAGE  KENT    DISPLAYS 

1.  Contact/Track   Oncertainity   Ellipse 
-Designated    Surface  Target  X 
-Unintended    Targets  X 

If   selected    by   operator. 

2.  Predicted  Time-OE-Targe  t  X 

3.  Probability    of    Acquisition 
Numerical  value. 

-Designated   Targets  X 

-Unintended   Targets  X 

If   selected    by   operator. 

a.      Seeker    S^rch  Pattern  Outline  X 

For   selected  search   mode. 
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5.  Missile    Flight    Path  X 
For   all   selected    missiles. 

6.  Booster    Drop    Zone  X 

7.  Missile   Power  Applicaticn    Warning  X 

OTHER  '' 

1.  Test/Maintenance 
-Missile    BIT    Results 

-Go/Nc-Gc  Indication  X 

-Failure  Status    Cede  X 
-HSCLCS    BIT    Results 

-Go/Ko-Go   Indication  X 

-Failure  Status    Cede  X 

2.  Training  Mode 

^  Inherent  capability   provided   by 
system    design.    Design   to   utilize 
data    from  NTDS    and/or  external 
training  support    devices   via   an   RS 
232   serial    interface. 

-Contact/Track  Location     (actual  or 
simulated)  . 

-Off    Board    Source/NTDS  X 

-Own   Ship  Sensors/NTDS  X 

-Manual    Input  X 

-Own    Ship  Position    (actual   or   siraul-        X 
ated) . 

-Training  Scenario   Parameters 
-Environmental   Ccnditions  X 

-Operational  Planning   Selections  X 

3.  Data   Extract 

Design  to  be  compatible  with  an  RS 
232  serial  interface  to  provide  for 
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data   sxorage/display   in    off-line 
devices    (e.g.,    tape   cassette    recor- 
der) . 

•Targe-^/Targeting    Cata 
■Missile    Initialization    Data 
•EIT    Results 


X 
X 
X 


U.      Maicr  Display  Features 

-Variable  Range    Scale  X 

16K-,    32K',     6UK-,    128K-,    192K-,    or 

256K-yard  radius.   The  256K-yard   is 

the    default    scale. 
-Offset  X 

-Zcom  X 

8K-,    16K-  or   32K-yard  radius. 
-Special   Symbols  X 

-Cursor,    wi-tih   Bearing/Range   readout.  X 

Manually  controlled. 
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APPENDIX    D 
DATA    BASE    DESCRIPTIONS 

This   appendix  contains    the   data      base   descriptions    to   be 
used    in    the   simulation  model.    These   da-a   bases  include: 

1.  Environmental  Data    Base 

2.  launcher   and    Missile   Status    Data   Base 

3.  Menu/State   Data   Base 

U,  Ship   Parameter  Data    Base 

5.  Threat   Data    Base 

6.  Enqagement    Data    Base 

7.  Track  Data    Base 
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1.  Data    Base   Name:       ENVIRONMENTAL   DATA    BASE 

2.  Puroose:      This    data     base   contains   the   current      s-^a-^'^   of 

weather;      visibility,    sea    state,   winds,      rain, 
etc. 

3.  Data   Base   Ussrs: 

a.      Write   Access:      Environment   Data   Base   Manager 
t.      Read  Access:        Environment  Display 

Plan    Engagement 
U.      Data   Base  Elements:      Visibility 

Sea  state 

Hind-direction   and   speed 
Relative   Hamitity 
Te  mperatura 
Barometric  Pressure 
Precipitation 
5.      Operation  on    Data   Base:      Update    (manual  or  automatic) 

-  Add 

-  Delete 

-  Change  all  elements 
Display 
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1.  Data    Bas€   Name:       LAONCHER    AND    MISSILE    STATUS    DATA    BASE 

2.  Purpose:      This    data    base      will   ke^p    track   of      the    number 

and  type  of  missilss  available  for  launch. 
The  data  base  will  be  updated  by  feedback  from 
the   laurcher. 

3.  Data   Base  Users: 

a.  Write  Access:      Launcher   Missile    Status 

b.  Read  Access:        Launcher   Missile    Assignment 

Plan    Engagement 

Launcher   Missile    Status  Display 
U.      Data    Ease   Elements:      Launcher   Number 

Cannister  Number 
Missile   type 
Launch   Inhibit 
5.      Operations    on   Data  Base :      Update    -   Add 

-  Delete 

-  Change  all  elements 
Display 
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1.  Data    Base  Name:       MENO/STATE    DATA    BASE 

2.  Purpose:      This       data    base      will      contain      the    menus      for 

prcgraiD  operation  and  also  provide  the  states 
allowable  from  any  operation.  That  is  it  will 
provide  the  menus  necessary  to  access  all 
aspects  of  the  program. 

3.  Data   Base  Users: 

a.      Write  Access    :      None 

h.      Read  Access:  Display   Module 

a.      Data    Ease   Elements:      an  determined   at   this   time 
5.      Operations    on   data  Base:      Operator     can      selact      desired 

menu  item 
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1.  Data    Base   Name    :     SHIP   PARAMETER    DATA    BASE 

2.  Puroose:   This      data     base   will      maintain     all      ?ertin9nt 

information  pertaining  to  on=*'s  own  ship.  The 
design  allows  for  this  information  to  be  input 
manually  or   automatically. 

3.  Data   Base  Users: 

a.      Write   Access:     Ship    Parameter    Data   Base  Manager 
fc.      Read  Access:        Update   Track 

Plan    Engagement 
Ship    Parametar   Display 
U.      Data    Ease   Elements:      Course 

Speed 
Latitude 
Longitude 
5.      Operations    on   Data  Base:      Update    -   Chang?  all    elements 

Display 
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1.  Data    Ease    Name:       THREAT    DATA    BASE 

2.  Purpose:      This    cla-*:a   base   is  to  contain    a   list    of   ho=-il<=; 

surface  vessels  by  name  and  class.  Associated 
with  each  class  of  vessel  will  be  the  weapons 
platform,        ECM      capabilities,  and      optimum 

engagement      plan      for  attacking     that      vessel. 
(The      security      of   this      information      must     be 
considered   when      designing   the     Threat    Display 
and  Threat    Data    Ease  Manager    modules)  . 

3.  Data   Base  Users: 

a.  Write   Access:     Threat    Data   Base   Manager 

b.  Read  Access:        Threat   Display 

Analyze  Threat    Data 
U.       Data   Ease  Elements:      Ship   Name 

Nationality 

Ship   Class 

Weapons 

ECM   Equipment 

Engagement    Plan  Recommended 
5.      Opera^icns    on  Data  Base:      Dpdats    -   Add 

-  Delete  (Permissions) 

-  Change  all  Elements 

(Permissions) 
Display 
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1.  Data    Base   Name:        ENGAGE  MENI    DATA    BASE 

2.  Purpose    :      This    data   base   will  contain      a   track   name   and 

associated  engagement  plans  for  that  -rack. 
The  engagemenr  plan  may  be  generated  aurcmat- 
ically  by   the   computer   or    manually. 

3.  Data   Base  Osers: 

a.  Write  Access:    Calculate   Probability   of  Acquisition 

b.  R€ad  Access    :      Engagement  Plan   Display 
U,      Data    Ease  Elements:      Track   name 

Type    of   engagement      plan     (manual   or 
automatic) 

Number   of  missiles   to  fire 
Sequence   of    firing   missile  (s) 
Type    of    missile    zo   use 
Flight   pa-ch 
Wa  ypcints 
5.      Cperaticns    on   data  base  :      Update 

Display 
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1.  Dara  Base  Name:   TRACK  DATA  BASE 

2.  Purpose:   This  data   base  will   contain  the   posit-icn  of 

all   tracks    and   pertinent    information 
pertaining  to  the  track. 

3.  Data  Bas€  Dsers: 

a.  Write  Access:   Delete  Track 

Add  Track 

Course   and  Speed    Update 

Bearing,    Range   and   Position    Opdat? 

b.  Read   Access:        Display   Track    Data 

Plan    Engagement 
U.      Data    Ease  Elements:      Type   track    (friend  or   foe) 

Class   of   vassal 

Bearing 

Ra  nge 

Position    (lattitude    and   longitude) 

Course 

Speed 
5.      Operations    on  Data  Base:      Opdate    -   add 

-  delete 

-  change  bearing   range 
or  position 

Display 
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APPENDIX    E 
HCDOLE    DESCRIPTIOMS 

This   appendix      ccntains   the      module    descriptions      of  the 

modules      shown    in      Figure      2.1      through   Figure     2.4.      These 

modules   include: 

Control 

Process  Input 

Ship    Parameter   Data   Base  Manager 

Environmental    Data    Base    Manager 

Threat    Data    Base   Manager 

Convert  Coordinates 

Type   Track 

Delete   Track 

Update   Track 

Course   and  Speed    Update 

Bearing,    Range,    ana  Position   Update 

Add  Track 

Launcher  and    Missile  Assignment 

Launcher  and    Missile   Status 

Plan    Engagement 

Plan    Enaagement   Data   Base    Manager 

Engaaemenx    Data 

Threat   Data 

Probability  of   Acquisition 

Uncertainty  Ellipse 

Display 

Menu   Display 

Launcher  and    Missile  Sta-us   Display 

Envirorniental    Display 

Engagement    Display 

Threat    Display 

Au-omatic   Bngagement   Disolay 

Graphics  Display 

Manual    Engage  lent    Display 

Ship    Parameter  Display 

Track    Display 
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1.  Module    Name:       CONTROL,     NUMEEE    0 

2.  Module    Purpo.'=e:      Iha      Control     moduls      calls      all      cth'rr 

modules      and     da-nermines        the      program 
flow, 

3.  Subordinate    Modules:      Process    Input     (1) 

Launcher  Missile    Assignment     (3.1) 
Plan    Engagement    (3.2) 
Display    (4) 

U.      Objects    Osed   by    the   Module:    Manual   inputs 

5.      Operations    Module   Performs:      Selection      of        subordinate 

modules   to      perform    program 
operation . 


1.  Module    Name:       PROCESS    INPUT,    NaMBER     1 

2.  Module   Purpose:       Selects      subordinate    module      xo      update 

corresponding  data    bases, 

3.  Subordinate    Modules:      Ship   Parameter      Data   Base      Manager 


(1.1) 

Environmental      Data      Base      Manager 

'1.2) 

onvert   Coordinates    (2) 
Threat   Data   Base   Manager    (1.3) 


^ 


4.  Objects    Used  by    the   Module:      Manual      Inputs        to      update 

modules 

5.  Operations    Module  Performs:      Selects   appropriate      subor- 

dinate     module        to      update 
corresponding  data    base. 
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1.  Module    Name:       SHIi    PARAMETER    DATA       BASE    MANAGER,       NUMBER 

1.  1 

2.  Module    curpose:      Update    the   Ship   Parameter     Data   3as=   by 

either    manual  or   automatic   means, 

3.  Subordinate    Modules:      None 

U.      Objects    Dsed  by    the   Module:      Ship   parameter   input   data 

5.      Operations    Module   Performs:      Update  of  the  Ship 

Parameter    Data   Base. 


1.  Module    Name:       ENVIRONMENTAL    DATA      BASS    MANAGER,  NUMBER 

1.  2 

2.  Module   Purpose:       Update   the      Environmental   Data      Base   by 

either    manual  or    automated   means, 

3.  Subordinate    Modules:      None 

4.  Objects   Used  by   the   Module:      Environmental        input  or 

upda-ce    data, 

5.  Operations    Module  Performs:      Update   of   the  Environmental 

Data    Base. 


1.  Module    Name:       THREAT    DATA    BASE    MANAGER,    NUMBER    1.3 

2.  Module    Purpose:      Update   the     Threat    Data   Base      by    either 

manual  means  or  through  the  use  of  a 
standard  chip  that  can  be  periodically 
updated  and  sent  to  all  ships  with 
HARPOON    capability, 

3.  Subordinate    Modules:      None 

U.      Objects   Used   by    the    Module:      Data      used      to      update      the 

Threat   Data    Base. 

5.      Operations    Module   Performs:      Update   of     the  Threat      Data 

Base. 
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1.  Module    Name:       CONVERT    COORDINATES,    NUMBER    2 

2.  Module   Purpose:       lo  convert      all    inputs  to     apda-ce   track 

data  to  common  coordinates.  The  ir.outs 
can  be  manual,  from  own  ship's  trackina 
equipment,  or  from  a  NTDS  link  from 
cthar    flatforms. 

3.  Subordinate    Modules:      Type   Track     (2.  1) 

U.      Objects    Used  by    the   Module:      Information    used      to    update 

the        Track  Data        Base, 

bearing,  range  and  posi- 
tion. 

5.      Operations    Mcdule  Performs:      All      sources   of      input      for 

the  Track  Data  Base  are 
converted  to  common  coordi- 
nates whether  they  are 
manual,  NTDS         or        from 

another   source. 


1.  Module    Name:      TYTE  TRACK,    NUMBER    2.1 

2.  Module   Purpose:       Type   Track      determines  if  the      -crack    is 

to  be  deleted  from  the  database,  added 
to  the  database,  or  some  parameters  of 
a  oresent  track  are  to  be  altered. 
These        actions        are  performed        by 

selecting  the  appropriate  subordinate 
nodule  . 


Subordinate    Modules:      Delete   Track 

Update   Track 
Add    Track    (2.  t.3) 


(2.  1,1) 


U.      objects   Used  by    the   Module:      Classification        of  ■^-yP'= 

update  to  be  performed; 
addition,  deletion  or 

alteration  to  the  Track 
Data   Base. 

5.      Operations    Mcdule  Performs:      Selection  of  delete, 

update,  or  add  track  subor- 
dinate modules  based  on 
track   type. 
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1.  Module    Name:       DELETE    TRACK,    NUMBER    2.1.1 

2.  Module   Purpose:      To   eliminate   -racks    from      the    data   base 

that      the      operator   determines      are     no 
longer    useful. 

3.  Subordinate  Modules:   None 

U.      Objects   Used   by    the   Module:      None 

5.      Operations    Module  Performs:      Track      identified        to  the 

Delete        Track      module  is 

removed   from   the    Track  Data 
Base. 


1.  Module    Name:       UPEATE   TRACK,    NUMBER    2.1.2 

2.  Module   Purpose:       To   update    the      information   contained  on 

tracks    in   the  Track   Data   Base. 

3.  Subordinate    Modules:      Course   and    Speed    (2.1.2.1) 

Bearing   and   Range    (2.1.2.2) 

4.  Objects   Used  by    the   Module:      Bearing      and   range      from     a 

fixed    point. 

Elapsed  time. 

Own    ship   course   and  sperd. 

Target    course  and   speed. 

5.  Operations    Module  Performs:      Determines      which      subordi- 

nate module  is  to  be  called 
to  perform  the  desired 
update. 
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1.  Module    Nams:       COUBSE    AN E    SPEED   UPDATE,     NUMBER     2.1.2.1 

2.  Module   Purpose:      To   updat*;    the   course   and   speed    infcraa- 

tion  on  each  track  contained  in  the 
Track    Data   Base. 

3.  Sutordinate    Modules:      None 

U.   Objects  ased  by  the  Module:   Own  ship  course  and  soeed. 

Ellapsed  time. 
Bearing   and  range   from  a 
fixed  point. 
NTDS  link  information. 

5.   Operations  Module  Performs:   Determines  course  and  speed 

of  tracks  based  on 
bearing/range  and  ellapsed 
time  when  entered  manually 
and  updates  Track  Data 
Base.  with  automared  track 
information  available 
(a.g.,  NTDS)  module  updates 
Track  Data  Base  with  the 
givan  course  and  speed. 

1.  Module    Name:       BEAEING-  RANGE,  AND      POSITION       UPDATE, 

NUMBER    2.  1.2.2 

2.  Module    Purpose:      To   update     the   bearing/range      and    posi- 

tion (Latitude  and  Longitude)  informa- 
tion on  each  track  contained  in  the 
Track    Data   Base. 

3.  Subordinate    Modules:      None 

U.      Otjscts    Used  by    the   Module:      Own      ship      sensor      informa- 
tion . 
NTDS    link   information 

5.      Operations    Mcdule   Performs:      Determines  bearing/range 

and  position  of  tracks 
based  on  own  ship  sensor 
information  and  own  ship 
position,  when        entered 

manually  and  updates  Track 
Data  Base.  With  automated 
track  information  available 
(e.g.,  NTDS)  module  updates 
Track  Data  Base  with  the 
given  bearing/range  and 
position. 
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1.  Module  Name:   ADD  TRACK,  NOMBEH  2.1.3 

2.  Module  Purpose:   To  allow   new  tracks   to  be   inpui  into 

the  Track  Daza  Base. 

3.  Subordinate  Modules:   None 

U.   Objects  Used  by  the  Module:   Coarse,    speed,    bearing, 

range,  position,  identifi- 
cation of  track  (friend  or 
foe  and  ship  class)  . 

5.   Operations  Module  Performs:   Permits  xhe  addition  of  new 

tracks  into  the  Track  Data 
Base. 


1.  Module    Name:      LAUNCHER    MISSILE   ASSIGNMENT,    NUMBER    3.1 

2.  Module    Purpose:       Allow      the        operator      to        bypass      the 

engagement  planning  capabilities  of  the 
computer  system  and  simply  select  and 
launch    the   desired   missiles. 

3.  Subordinate    Modules:      Launcher   and  Missile  Status 

U.      Objects    Dsed  by    the   Module:      Inputs   from     operator    iden- 
tifying  which      launcher   and 


missiles  to  be  fired  in 
which  bearing,  range  and 
waypoints    if   desired. 


5.      Operations    Module   Performs:      The  Launcher  Missile 

Assignment  module  allows 
the  operator  to  manually 
sslact  a  launcher  ana 
missile  to  be  fired  in  a 
given  direction  similar  to 
the  present  capabilities  of 
tne  HARPOON  Weapons  System. 
The  automated  engagement 
planning  functions  of  this 
program   are   bypassed. 
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1.  Moduls    name:       LAUNCHER     AND    MISSILE    STATUS,    NUMBER    3.1.2 

2.  Module   Purpose:       lo   provide   currant      informaticn   on   what 

launchers  (port  and  starboard)  are 
ready  to  firs  and  which  and  what  type 
missiles    are  ready    for   firing, 

3.  Sutordinate  Modules:   None 

U.   ObiecTS  Used  by  the  Module:   Which   launchers  (port   and 

starboard)  are  ready  to 
fire.  Which  and  what  type 
missiles   are  ready    for 

firing. 

5.   Operations  Module  Performs:   The   Launcher  and   Missile 

Status  module  receives 
automated  inputs  from  sach 
launcher  on  zhe  status  and 
type  of  all  missiles.  This 
information  is  used  to 
update  -Lhe  Launcher  and 
Missile  Status  Data  Base. 
When  queried  by  either  -he 
Launcher  and  Missile 
Assignment  module  or  the 
Engagement  Data  module,  the 
Launcher  and  Missile  Status 
module  can  return  the 
status  of  launchers  and 
missiles. 
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1.  Module    Name:       PLAN  ENGAGEMENT,    NUMBER    3.2 

2.  Module    Purpose:      To      determine     the      optimum      engagement 

plan  for   a   given    target. 

3.  Subordinate    Modules:      Plan    Engagement    Data     Base   Manager 


(3.2.1) 

Engagement    Data    (3.2.2) 
Probability   of    Acquisition    (3.2.3) 


4.  Oti<»cts    Used  by    the   Module:      Which      track      to      plan      the 

engagement    for. 

5.  Operations    Module  Performs:      Tha    Plan      Engagement    module 

is  the  heart  of  this  soft- 
ware program.  This  module 
determines  an  optimum 

engagement  plan  for  desired 
•carg3-s.  The  targets  that 
have  an  engagement  plan 
computed  can  be  identified 
eiuhar  by  a  selective 
manual  input  or  can  be 
automatically  generated  for 
all  contacts  that  are  clas- 
sified hostile  (This  latter 
process  would  require  a 
slight  modification  to  the 
design;  an  input  to  the 
Plan  Engagement  must  be 
received  from  the  type 
track      module)  .  Through 

access  to  the  Threat  Data 
Base,  Launcher         Missile 

Status        Data  Base        the 

optimum  plan  for  engaging  a 
selected  target  can  be 
computed.  The      functions 

performed  by  this  module 
can  greatly  assist  the 
Tactical  Action  Officer  in 
tha  performance  of  his 
duties . 
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1. 

2. 

3. 
4. 


Module  Name: 
Module  Purpose: 


PLAN  ENGAGEMENT  DATA  BASE  MANAGER, 
3.  2.1 


To      upda- 

Ease. 


:e     the-     Engagement 


Sutordinate    Modules:      None 
Obiects   Used   by    the   Module 


5.      Operations    Module  Performs: 


NDMEER 
Plan      Data 


Engagement  olaE 
ated  by  the  Enqa 
Module . 


_n    as      gener- 
gagement    Plan 


The  Plan  Engagement  Data 
Bass  Manager  enters  all 
engagement  plans  that  the 
Plan        Engagement  module 

generates  into  a  Plan 
Engagement  Data  Base.  This 
way  a  list  of  the  engage- 
ment plans  for  all  appli- 
cable targets  is  kept 
current   in   a   data   base. 


1.  Module    Name:       ENGAGEMENT    DATA,    NUMBER    3.2.2 

2.  Module   Purpose: 


Ihe  Engagement  Data  module  supplies  the 
data  needed  by  the  Plan  Engagement 
nodule    to   generate    the    Engagement    Plan. 


Subordinate    Modules: 


and 


Launcher 

(3.1.2) 

Threat    Data    (3.2.2.  1) 


Missile        Status 


Objects   Used  by    the   Module: 


Operations    Module  Performs 


Which  launcher  and  missiles 
are  ready  to  fire. 
All  pertinent  information 
on  hostile  ship  class, 
weapons.  ECM  eguipment  ana 
best  strategy  for  attack 
contained  in  the  Threat 
Data    Base. 

The  Engagement  Data  module 
coordinates  the  passing  of 
all  data  base  information 
needed  to  generate  an 
engagement  plan  to  the  Plan 
Engagement  module.  In  this 
design,  that  information  is 
contained  in  the  Launcher 
and  Missile  Status  module 
and    the   Threat    Data   module. 
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Module    Name:       THREAT   DATA^    NUMBER    3.2.2.1 


Module    Furposa: 


To  provide  the  infcrmaticn  contained  in 
the  Threat  Data  modul=  -o  the 
Engagement    Data    module   when    requested. 


Suhordinate    Modules:      None 
Objects   Used   by    the   Module: 


Operaticns    Module  Performs: 


All  elements  contained  in 
xhe  Threat  Data  Base,  shiD 
class,  weapons,  platform. 
SCM  capability  ^"-^  K^<=-t 
plan    for    attacx. 


and      besu 
module 


The        Threat      Data 
provides        the        Engagement 
Plan   module    with    all   of   the 
informaxion  that  is 

contained  in  the  Threat 
Data    Base.  This    infcrrca- 

tion  is  then  used  to  deter- 
mine the  optimum  engagement 
plan. 
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1.  Module    Name:       PROBABILIIY    OF    ACQUISITION,    NDHBER    3.2.3 

2.  Module    Purpose:      To      determine   what      the   probability     is 

that  if  a  missile  is  launched  at  a 
given  targe-  that  the  missile  can 
acquire   ana   hit    that   target. 

3.  Subordinate    Modules:      Oncertainty   Ellipse    (3.2.3.1) 

4.  Objects    Ossd   by    the   Module:      The    figure   generated   by   the 

Uncertainty  Ellipse  module. 
Type  missile  to  be  launched 
ana  search  pattern. 
Type  target  to  be  attacked 
and  its  physical  character- 
istics and  ECM  capabili- 
ties . 

The  Probability  of 

Acquisition  module  uses  the 
type  missile  fired,  range 
to  target,  and  target  char- 
acteristics to  generate  the 
probability  that  the 

missile  can  acquire  and  hit 
the      given      target.  This 

information  along  with  the 
value  obtained  from  the 
Uncertainty  Ellipse  module 
is  then  passed  to  the  Plan 
Engagement  module  where 
they  become  elements  of  the 
engagement  plan  maintained 
in  the  Engagement  Plan  Data 
Base . 


5.      Operations    Module  Performs: 
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1.  Module    Name:       ONCERTAINTY    ELLIPSE,    NUMBER    3.2.3.1 

2.  Modul*?    FuEDoss:      To      detenine      the    probability      -ha*      a 

given  missile,  or  set.  of  missil-Bs. 
fired  at  a  specific  target  will  sink 
that   target. 

3.  Subordinate    Modules:      None 

U.      Objects    Dsed  by    the   Module:      Number      of   missiles      to      be 

Probability  of      acquisition 
of  the   target. 
Lethal  capability  of 

missiles    fired. 

5.      Operations    Module  Performs:      The        Uncertainty        Ellipse 

module  takes  the  number  and 
capabilities  of  missiles 
fired  and  combines  these 
values  with  the  probability 
of  acquisition  to  generate 
the  probability  of  a  target 
kill.  The  Uncertainty 

Ellipse  module  can  generate 
ellipses        with  assigned 

probabilities  stating  rhat 
total  destruction  of  the 
target  will  occur  if  it  is 
within  one  elliose,  50% 
disability  of  the  target 
will  occur  if  it  is  within 
a  second  ellipse,  etc. 
These  ellipses  will  account 
for  rhe  fact  that  hostile 
target  positions  may  net  be 
completely  accurate. 
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1.  Mcdul€    Name:       DISPLAY,     NUMBER   4 

2.  Module    Purpose:      To    call      subordinate   modules      as    neces- 

sary to   generate    required  displays. 

3.  Subordinate    Modules:      Menu   Display    (4.1) 

Launcher        ana  Missile        Status 

Display    (4.2) 
Environmental    Display    (4.3) 


Environmental    Display    (4.j) 
Engagement    Display    (4.4) 
ShiD   Parameter   Disolay     (4.5) 
Track   Display    (4.6f 

4.  Objects    Used  by    the   Module:      Display   requests, 

5.  Operations    Module  Performs:      The      Display      module      calls 

the  required  modules  to 
generate  display  as  neces- 
sary. 


1.  Module    Name:       MEND  DISPLAY,    NUMBER   4.1 

2.  Module    Purpose:      To   access   the  Menu/State     Data    Base   and 

display  the  required  menu  when  called 
and  keep  track  of  the  state  of  the 
frogra  m. 

3.  Subordinate    Modules:      None 

4.  Objects    Used  by    the   Module:      Information      contained        in 

the    Menu/State  Data   Base. 

5.  Operations    Module  Performs:      The      Menu        Display      module 

will  access  the  Menu/State 
Data  Base  and  provide  the 
necessary  menu  for  display 
when        prompted  by        the 

Display    module.  The   Menu 

Display  module  will  also 
keep  track  of  the  state  of 
th=  program,  that  is  what 
menus  can  be  displayed 
given  thax  ~he  state  of  the 
program  exists  now  with  a 
current  menu. 


91 


1.  Module    Name:       LADUCHER       AND         MISSILE       STATUS  DISPLAY, 

NaMBER    4.2 

2.  Module    EuTDOse:      To      access      the      Launcher     and      Missile 

Status  Data  Base  and  provide  a  display 
of  the  information  contained  in  -har 
data   base. 

3.  Subordinate    Itodules:      None 

U.      Otjects    Used  by    the   Module:      Information      contained        in 

the  Launcher  and  Missile 
Status   Data    Bass. 

5.      Operations    Module  Performs:      The      Launcher     and      Missile 

Status  Display  module  will 
display  the  information 
contained  in  the  Launcher 
and  Missile  Status  Data 
Base  when  prompted  by  the 
Display   module. 


1.  Mcdule    Name:       ENVIRONMENTAL    DISPLAY,    NUMBER    4.3 

2.  Mcdule   Purpose:      To  a.ccess      the   Environmental      Data    Base 

and   provide      a   display   of     the    informa- 
tion contained   in   -chat  data    base. 

3.  Subordinate    Modules:      None 


U.   Objects  Used  by  the  Module:   Information  contained  in 

the    Environmental  Data 
Base . 

5.   Operations  Module  Performs:   The   Environments   Display 

module   will   display  the 

information  contained  in 

the  Environmental  Data  Base 

when    orompted    by  the 
Di sp la  y" module. 
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1.  Mcdal€    Name:       ENGAGEMENT    DISPLAY,    NUMBER    U.  U 

2.  Module    Purpose:      To   graphically   disolay      the    flight   path 

cf  missiles  thax"  are  to  be  flown 
against  a    set  target.  Threat    data   on 

the  target  will  also  be  displayed.  The 
engage  lent  play  will  have  the  capa- 
bility to  be  superimposed  ever  .he 
general   track  display. 

3.  Subordinate    Modules:      Threat    Display    (4.4.1) 

Automatic   Engagement    (4.4.2) 
Manual    Engagement    (4.4.3) 

4.  Objects   Used  by    the   Module:      Threat      Data  Base      informa- 

tion. 

Engagement   Plan  Data  Base 

inf  orma  wion. 

Manual        inputs  for        an 

engagement   plan. 

5.  Operations    Module   Performs:      The        Engagement  Display 

module  calls  upon  subordi- 
nate modules  to" provide  the 
operator  a  display  of  rh? 
computer  generated  engage- 
ment plan  constructed  by 
the      operator.  In      both 

cases,  the  threat  data 
pertinent  to  the  displayed 
target   can   also    be   shown. 
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1.  Module    Name:      THEEAT    DISPLAY^    NUMBER    4.4.1 

2.  Modale   Purpose:     .  lo     5.ccess     the    Threat      Data      Base      and 

provide      a   disolay      of  the      infer maiion 
contained    in   that  data   base. 

3.  Subordinate    Modules:      None 

U.      Obiects    Dsed  by    the   Module:      The      information      contained 

in   the   Threat  Data   Base. 

5.      Operations    Module  Performs:      The      Threat    Display      module 

will  display  the  informa- 
tion contained  in  the 
Threai:        Data        Base        when 

grompted    by     the    Engagement 
isplay   module. 


1.  Module    Name:       AOTCMATIC    ENGAGEMENT    DISPLAY,    NUMBER    4.4.2 

2.  Module   Puroose:      To   graphically      display  the      engagement 

plan  that  was  generated  by  the  Plan 
Engagement  module  and  stored  in  the 
Engagement   Plan    Data   Base. 

3.  Subordinate    Modules:      Graphics  Display    (4.4.2.1) 

4.  Objects   Used   by    the   Module:      Information      contained        in 

the  Engagement  Plan  Data 
Base . 

5.  Operations    Module  Performs:      The      Automatic        Engagement 

Display  module  provides  a 
graphical  representation  of 
the  engagement  representa- 
tion or  the  engagement  plan 
as  contained        in  the 

Engagement  Plan  Data  Ease. 
All  missile  trajectcries 
and  waypomts  will  be 
depicted  with  associated 
missile  fire  times  and 
arrive  over  the  target 
time.  The        uncertainity 

ellioses  will  also  be 
generated  along  with  the 
probability  of  acguisition 
of    the    target. 
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1. 

2. 
3. 

a. 


Module    Name:       GRAPHICS    DISPLAY,    NUMBER    4.4.2.1 


Module   Purpose: 


lo  provids  graphics  capabili 
Auroraatic  Engagemer.-  Display 
the   Manual   Engagement   Disola 


ties   to   the 
module   and 
y    module. 


Subordinate    Modules:      None 
Objects    Dsed  by    the   Module: 


5.      Operations    Module  Performs: 


Engagement      Plan 
information. 
Manually      input 
plan . 

The  Graphics  Dis 
provides  the  gra 
bilities  necess 
Automatic  Manual 
Display  module 
rately  portray 
engagement   plans 


Data      Base 
engagement 


play  module 
phics  caca- 
ary  to  the 
Engagement 
to  ac  cu  - 
their    aiven 


1. 
2. 

3. 

4. 


Module    Name:       MANCAL    ENGAGEMENT    DISPLAY,    NUMBER    4.4.3 

Module    Purpose:      To   provide  the      operator   the    capability 

to     manually  inpur      an   engagement      plan 
for    attacking  a    given   target.. 


Subordinate    Modules:      Graphics  Display    (4.4.2.1) 
Objects   Used   by    the   Module: 


5.      Operations    Module   Performs 


Informa-ion     contained 
the    Threat   Data    Base. 


m 


The  Manual  Engagement 
Display  module  allows  the 
operator  to  manually  input 
his  own  engagement  plan  for 
a  given  target.  Once  this 
information  is  graphically 
input  to  the  display,  it 
can  be  transferred  zo  -he 
Engagement  Plan  Data  Base 
where  it  can  be  programmed 
to  the  missiles  like  an 
automatically  generated 
plan . 
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1. 

2. 

3. 

U. 


Mcdul€    Name:       SHIF    PARAMETERS    DISPLAY,    NUMBER    4.5 

Module   PuTDOse:       To  diCCBss   tha   Ship      Parameter    Data    Base 

and   provide      a   display   of     the    infcrira- 
tion  contained   in   that   data    base. 


Subordinate    Modules:      None 
Objects    Dsed  by    the   Module: 

Operations    Module   Performs: 


Information  cor.tai.ned  in 
the  Ship  Parameter  Data 
Base. 

The  Ship  Parameter  Display 
module  will  display  'the 
information  contained  in 
the  Ship  Parameter  Data 
Base  whan  prompted  by  the 
Display   module. 


1, 

2. 

3. 
4. 


Module    Name:       TRACK    DISPLAY,    NUMBER    U.6 


Module    Purpose: 


To      access      tha      Track      Data      Base  and 

provide      a      continuous   display      of  all 

tracks    beings      maintained  m      that  data 
bask. 


Subordinate    Modules:      None 
Objects   Dsed  by    the   Module: 

Operations    Mcdule  Performs: 


Information     contained 
tha    Track   Data   Base. 


m 


The  Track  Display  mcdule 
will  continuously  display 
all  tracks  maintained  in 
rhe  Track  Data  Base.  These 
tracks  will  be  constantly 
upda-ed  as  the  Track  Data 
Base         is      updated.  The 

symbology  and  methcd  pres- 
entation of  the  tracks 
should  closely  coincide 
with    NTDS    displays. 
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APPENDIX    P 
STSIEM    DESIGN    USING    ADA 


packaqe   UPDATE    is 

tyce    NEfi    LAONCHERS; 

"tvce    MAXSPEED* 

LAO    NBE    :    integer    range    1..NER   LAONCHERS; 

CAN   N3R    :    integer    range    1..7; 

MISS   type    :   integer  range    1..7; 

LAO    INHIBIT    :    bool€an; 

COURSE    :    integer    range    0.  .359: 

SPEED    :    integer  range   O..MAXSPEED; 

tvc€   LATITUDE    is    record 

DEGREES    ;    integer   range   -90.. 90; 
MINUTES   :    integsr   range    0..60; 
SECONDS    :    integer   range    0..60; 
end   record; 
type    LCNGITDDE  is    record 

DEGREES   :     inteqsr   range    -180.. 180; 
MINUTES   :    integer   range    0..60; 
SECONDS    :    intecer   range    0..60; 
end   reccrd; 
VISIBILITY  :    integer  range   0..30; 
SEA   STATS    :    integer  range    0..10: 
WIND   DIHECTION   :    integer    range   0..359; 
WIND   SPEED  :     integer  range    0..100; 
RELATIVE    HUMIDITY    :   integer    range    0..100; 
TEMPERATURE   :    inteaer  range    -100.. 130: 
EARCMETEIC  PRESSURE    :    integer   range    900, .1100; 
PRECIPITATION    :    boclean; 
HOSTILE    NAME    :    str  ing  ( 1.  .  12)  ; 
SHIP   CLASS  :     strinq(1..9)  : 
NATIONALITY    :    String  (1  ..  1  0)  ; 
WEAPONS    :    string  (1  ..50) ; 
ECM    EQUIPMENT    :    St  ring  (1  .  .50)  ; 
ENGAGEMENT  METHOD    :   s^rin  g  ( 1 . .  50)  ; 
task    LAUNCHER    MISSILE    STATUS    is 

entry    UPDATE   LAU  (LAUNCHER    NUMBER    :    in    LAU    NBR ; 
CANNISTER    "SOMBER    :    in    CSN   NBR; 
MISSILE  tyce    :    in   MISS   type; 
LAUNCHER    INHIBIT    :    in    lAO    INHIBIT); 
end   LAUNCHER    MISSILE   STATUS;    " 
task    SHIP    PABAMETEP  Is 

entrv    UPDATE   COUESEfSHIP    COURSE    :    in    COURSE)  ; 
entry    UPDATE"SPEED  (SHIP    ^PEED    :    in    SPEED)  ; 
enrrv    OPDAT  E"L  AT  ITODE  (ST5IP   LATITUDE    :    in    LATITUDE); 
entry    UPDATS"LONGITODE  ( SHIP    LONGITUDE    :    in    LONGITUDE) 
end    SHIP    PARAM"ET3R; 
task    ENVIECNMENT    is 

entry    UPDATE    VI SIBILITY  (VIS    :    in    VISIBILITY)  ; 
entry   UPDATE"SSA   STATEfSEA    :    in    SEA    STATE)^; 
entry    UPDATE'WIND   DIRfWINDDIR    :    in   "^IND    DIRECTION)  ; 
entrv    UPDATE"WIND"'SPEED  (WINDSPD    :    in    WITTD   SPEED[; 
entry    UPDATE~REL   "HUM(RELHDM    :    in    RELATIVE~HUMIDITY)  ; 
entrv    UPDATE    TEMTERA TORE  (TEMP    :    in    TEMFERlTURE)  ; 
entry    UPDATE~BAR    PRESS ( EARPRESS    :    in 

BARCMETRICPRS^SUREI  ; 
entrv    UPDATE'PRECIP (PRECIP    :    in    PRECIPITATION); 
end    ENVIRONMENT; 
task    THREAT    is 

entry    ADD  (HOSTILE    :    in    HOSTILE    NAME; 
NATION     :    in    NATIONALITY; 
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SHIP   :     in    SHIP  CLASS; 
WEPS    :    in   WEflE(3NS; 
ECM    :    in    ECM    EQUIPMENT; 
METHOD     :    in    "ENGAGEMENT    METHOD); 
antry    DELETE (HOSTILE     :    in    HOSTILE    NAME; 

NATION    :    in    NATIONALITY)  ; 
entry    UPDATE    CLASS (HOSTILE    :    in    HOSTILE    NAME; 
NATION    :    in    NATIONALITY; 
SHIP    :    in    SHIP  CLASS)^: 
entry    UPDATE    WEP'5(H0STILE    :    in    HOSTILE    NAME; 
KATION    :    in    NATIONALITY; 
WEPS    :     "^  n   WEAPONS)  ; 
entry    UPDATE    ECM(HOSTILE    :    in    HOSTILE    NAME; 
NATION    :    in    NATIONALITY; 
ECM    :    in    ECM    EQUIPMENT),; 
entry    UPDATE    M'ETHOD(HOSTILE    :    in    HOSTILE   NAME; 
NATION     :     in    NATIONALITY; 
METHOD     :    in    ENGAGEMENT    METHOD); 
end    THREAT; 
end    UPDATE: 
package    bcdy  UPDATE    is 

task    body    LAUNCHER_MISSILE_STATUS    is 
begin 

acce'Tt    UPDATE    LAU  (LAUNCHER    NUMBER    :    in    LAU    NBR; 
CANKISTER     NUMBER    :    in    CATJ    NBR; 
MISSILE   type    :    in   MISS    type; 

LAUNCHES  Inhibit  :  in  iau  inhibit)   do 

--   insert   additional   body    oT    UPDATE   LAU 

end    UPDATE    LAU; 
end    LAUNCHER'MISSILE  STATUS; 
task    body    SHIP_PARAMETER    is 
begin 

accept    UPDATE   CO  URSE  (SHIP_COURSE    :    in    COURSE)     do 

--   insert  additional   body   of   UPDATE   COURSE 

end    UPDATE    COURSE; 

acceot    DPD5TS   SPEED (SHIP    SPEED    :    in    SPEED)    do 

--   insert  additional   body   of   UPDATE   SPEED 

end    UPDATE    SPEED; 

acc9ot    UPD"ATE   LATITUDE  ( SHIP   LATITUDE    :     in    LATITUDE)    do 

--   insert   additicral  body   cf    UPDATE    LATITUDE 

end    UPDATE    LATITUCE; 

accept    UPDSTE_LONGITUDE (SHIP   LONGITUDE    :    in    LONGITUDE) 
do  " 

—  insert   additional    body   of   UPDATE   LONGITUDE 
end    UPDATE    LONGITUDE; 

--    insert    additional  body    of   task   SHIP    PARAMETER 
end    SHIP    PARAMETER; 
task    body    ENVIRONMENT    is 
begin 

acceTDt    UPDATE   VISIBILITY  (VIS    :    in    VISIBILITY)     do 

—  insert   addlticnal  body    of    UPDATE    VISIBILITY 
end    UPDATE    VISIBILITY; 

accept    UPDATE   SEA   STATE(SEA    :    in    SEA    STATE)     do 

—  insert   addlticnal  body    cf    UPDATE   ^EA   STATE 
end    UPDA'^E    SEA    STATE*  ""        " 

accent    UPDATE   ¥IND   DiR(WINDDIR    :    in    WIND    DIRECTION)     do 

--   insert   additional   body    of    UPDATE    HIND~DIR 

end    UPDATE    WIND    DIR: 

accent    DPD5TE    WIND    SPEED  (WINDSPD    :    in    WIND   SPEED)     do 

--   insert  additional   body    of   UPDATE    WIND    SPEED 

end    UPDATE    WIND    SPEED; 

acceot    UPDSTE    R"EI    HUM(HUM    :    in    RELATIVE    HUMIDITY)     dc 

—  insert  additicral  body   cf   UPDATE    REL"HUM 
end    UPDATE    REL    HUM; 

acceot    UPDATE  TEMPERATU  RE  (TEMP    :     in    TEMPERATURE)     do 

—  insert  additicral  body   cf    UPDATE   TEMPERATURE 
end    UPDATE    TEMPERATURE; 

accect    UPDATE   BAR   PRESS  (BARPRESS    :    in 
BABCMETRIC_rRES'SURE)      do 
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--   insert  additional    body    of   UPDATE   BAR   PRESS 
€nd    UPDATE    BAR    PRESS; 

accsot    UPDATE   PRECIP  (PR  ECIP    :    in    PRECIPITATION)     io 
--   insert   additional   body   of   UPDATE   PRECIP 
€nd    UPDATE    PRECIP*  " 

--    insert   additional  body    of   -ask    ENVIRONMENT 
end    ENVIRONHENT: 

task    body   THREAT    is 
begin 

acceot   ADD  (HOSTILE    :    in    HOSTILE    NAME; 
NATION     :    in    NATIONALITY; 
SHIP   :    in   SHIP  CLASS; 
WEPS  :    in  WEAPONS; 
HCM    :    in    ECM    EQUIPMENT; 
METHOD     :    in    ENGAGEMENT_METHOD)     do 
--   insert    additional    body   of  ADD 
end   ADD; 
acceot   DELETE  (HOSTILE    :    in    HOSTILE   NAME; 

NATION     :     in    NATIONALITY)     do 
--    insert    additional    body  of   DELETE 
end    DELETE; 

acc6Dt   UPDATE    CLASS (HOSTILE    :    in    HOSTILE   NAME; 
NATION    :    in"NATION ALITY; 
SHIP    :     in    SHIP_CLASS)     do 
--    insert    additional    body   of   UPDATE   CLASS 
end    UPDATE   CLASS*  ~ 

acceot   UPDATE    WEPS (HOSTILE    :    in    HOSTILE    NAME; 
NATION    :    in'NATIONALITY; 
WEPS   :     in   WEAPONS)     do 
--   insert    additional    body   of  UPDATE   WEPS 
end    UPDATE    WEPS; 

accSDt   UPDITE    ECM (HOSTILE    :    in    HOSTILE    NAME; 
NATION    :    in'KATIONALITY; 
ECM    :    in    ECM    EQUIPMENT)     do 
--   insert    additional    body  of  UPDATE   ECM 
end    UPDATE   ECM; 

acC€Dt   UPDSTE     METHOD (HOSTILE    ;     in    HOSTILE    NAME; 
NATION    :    in'NMIONALITY; 
METHOD     :     in    ENGAGEMENT    METHOD)     do 
--   insert    additional    body   of  UPDATE   METHOD 
end   UP  DA  T  E   E  C  M  *  ~ 

—    insert    ADDITION 'body    of   task   THREAT 
end    THREAT; 
begin 

—   insert   additional    body  of   package    UPDATE 
end    UPDATE; 

package    ADTC  ENGAGEMENT    is 
tyce    NER    LAUNCHERS; 

LAU    NBR    :    integer    range   1  .  .NER_LAUN  CHERS; 
CAN   NBR    :    integer    range   1..U; 
MISSILE  type    :    integer   range    1..7; 
LAD   INHIBIT    :    boolean; 
HOSTILE    NAME    :    str  ing  M  . .  12)  ; 
NATIONALITY    :    str  ing  ("1 .  •  1  0)  : 
ENGAGEMENT   METHOD     :    string  (1  ..  50)  ; 

procedure   AUTO    ENGAGE(LAUNCHER   NBR    :    in    LAU    NBR; 
CANNISTER    NBH    :    in    CAN    NER;    " 
MISS    tyDe":    in   MISSILE^type ; 
HOSTILE"  :     in     HOSTILE    NlME; 
NATION   :     in    NATIONALITY; 
METHOD    :    out       ENGAGEMENT    METHOD); 
orocedure  PROB    ACQUISITIONTMETHOD    :    in   out 

ENGAGEMENT    METHOD)  ; 
procedure  UNCERTAINITY    ELLIPSE (METHOD    :    in   out 
ENGAGEMENT   METHOD)  ;    ~ 
end    ADTC    ENGAGEMENT; 
package    body   AUTO   ENGAGEMENT   is 

procedure    AUTO  ENG AGE(LAU NCHER    NBR    :    in   LAU    NBR; 
CANNISTER._NBH    :     in   CAN_NBR;    "" 
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MISS   type   :     in    MISSILE    type; 

HOSTILE    :    in    HOSTILE    NlME; 

NATION    :    in    NATIONALITY; 

METHOD     :    out    ENGAGEMENT    METHOD)     is 
bsain  ~ 

--    insert    additional  body    of   procedure   AOTO   ENGAGE 
end    AUTO    ENGAGE: 
procedure    PROB   ACQOISITIO N (METHOD    :    in   out 

ENGAGEMENT_METHOD)    is 
begin 

—    insert   additional  body    of    procedure    PROB   ACQUISITION 
end    PBOE    ACQUISITION: 
orocedure    DNCEFTAINITY   ELLIPSE  (METHOD    :    in    cut 

ENGAGEMENT_flETHOE)    is 
begin 

--    insert   additional  body    of   procedure 
--    DNCERTAINITY    ELLIPSE 
end    UNCERTAINITY_EILIPSE; 
begin 

—  insert   additional    tody   of   package    AUTO    ENGAGEMENT 
end    AUTO    ENGAGEMENT; 

package    MANUAL    ENGAGEMENT   is 
tvc€    NER    LAUNCHERS; 

LAU    NEE    :    integer    range    1 . . NER_LAUNCHERS; 
CAN   NBR    :    integer    range    1..4; 
MISSILE  tvT3e    :    integer   range    1..7; 
LAU    INHIEIT    :     boolean: 
ENGAGEMENT   METHOD     :    string  (1  ..  50)  ; 

iDrocedure    MANUAL    ENGAGE  (LAUNCHER    NBR    :    in   LAU    NBR; 
CANNISTER    NBR    T    in    CAN    NBR; 
MISS   type":    in    MISSILE~type ; 
METHOD    :    out       ENGAGEMETIT    METHOD); 
end    MANUAL    ENGAGEMENT; 
package    bcdv  MANUAL    ENGAGEMENT    is 

orocedure'MANUAL    J:ngaGE(L  AUNCHEH   NBR    :    in    LAU    NBR;. 
CANNISTER   NBE   T    in   CAN    NBR; 
MISS    tyce":     in    MISSILE" type; 
METHOD    :    out    ENGAGEMENT_METHOD)     is 
begin 

--    insert   additional  body    of    procedure    MANUAL   ENGAGE 
end    MANnAI_ENGAGE; 
tagin 

—  insert   additional    tody   of   package    MANUAL    ENGAGEMENT 
end    MANUAL    ENGAGEMENT; 

package    DISPLAY    is 
tvre   MENU   type; 
tyoe    MAXSPEED: 

VISIBILITY  :     integer  range   0..30; 
SEA   STATE    :   integer  range    0..10: 
WIND   DIRECTION    :    integer    range    0..359; 
WINE   SPEED   :    integer  range   0..100; 
RELATIVE    HUMIDITY    :    integer    range    0..100; 
TEMPEBATOEE   :    integer  range   -100..  130: 
BAROMETRIC  PRESSURE   :    integer   range    900..1100; 
tyce    PBECIPITATION    is     (YES-NO)  ; 
COURSE    :    integer    range   0.  .359; 
SPEED    :    integer  range   O..MAXSPEED; 
tyce   LATITUDE    is    record 

DEGREES   :    integer   range   -90. .90; 

MINUTES    :    integer  range   0..60; 

SECONDS   :    integer  range    0,.60; 
end   record ; 
-vp€   LONGITUDE   is    record 

DEGREES    :    integer   range   -180..  180; 

MINUTES    :    inteaer   range    0..60; 

SECONDS   :    integer   range    0-.60; 
end   record ; 
HOSTILE   NAME    :    str  ing  M  . .  12)  ; 
NATIONALITY    :    string  (1 ..  1  0)  ; 
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SHIP   CLASS   :    string(1..9)  ; 

WEAPONS    :    string(1  ..50)  : 

ECM   EQUIPMENT    :   St  ring  (1 .  .50)  ; 

ENGBGEMENT   METHOD    :   srrin g  ( 1 . .  50)  ; 

TRACK    NUMBER    :    integer   range    100. .3199; 

TRACK  typ=    :    integer  range    1..7; 

VESSEL   CLASS    :    integer   range   0..1; 

tyce    MAXrange: 

HOSranqe    :    integer   range    O..MAXranga; 

BEARING    :    inteaer    range   0..359; 

HOSTILE    LAT    :     LATITUDE; 

HOSTILE    LCNG     :    LONGITUDE; 

ENGAGEMENT  PLAN    :     string ( 1 .. 50)  ; 

task    MENU    DISPLAY    is 

entry    ACCESS    MEND  (MENU     :    cut    MEND    type)  ; 
end    MENU    DISPLliY; 
task    LAUNCHER    MISSILE   STATUS    is 

entry    ACCESS   LM(LADT7CHER    NBR    :    out    LAD    NBR; 
CANNISTER    TJBR     :    out    C  ATI    NBR; 
MISS    type":    out   MISSI LE'type; 
INHIBIT   :    out    lAU    INHIBIT); 
end    LAUNCHER    MISSILE  STATUS; 
task    ENVIRONMENT    is   " 

en-ry    ACCESS    ENVrVIS    :    out    VISIBILITY; 
SEA    :    out    SEA    <TATE; 
WINDDIR    :    oufWIND    DIRECTION; 
WINDSPD    :    cut    WIND-SPEED; 
RELHDM    :     out    RELATIVE    HDMIDITY; 
TEMP    :    out    TEMEEEATORl; 
BARPRESS    :    out    BAROMETRIC    PRESSURE; 
FRECIP    :    out    P FECI PIT  ATI OU)  ; 
end    ENVIRONMENT; 
task    SHIP    PARAMETEF   is 

entry    ACCESS    SP  (SHIP   COORSE    :    out    CODRSE; 
SHIP    SPEED":    out   SPEED; 
SHIP 'LATITUDE     :    out   LATITDDE; 
SHIP    LONGITDDE    :    out     lONGITDDE) ; 
end    SHIP"  PARAMETER; 
task    TRACK    is 

entry    ACCESS    TR  (TRACK    NDM    :    our    TRACK    NDMBER; 
TRACK    TYP    :    out  TRACK    type; 
CLASS    :    out    VESSEL_CLISS; 
HNG    :    out    HOS range; 
BRNG    :    out    BEARING; 
HOST    LAT     :    out    HOSTILE   LAT; 
HOST    LONG     :    out    HOSTILE    LONG)  ; 
end   TRACK; 
task    THREAT   is 

entry    ACCESS    TH(HOSTILE    :    out    HOSTILE    NAME; 
NATION    :     out    NATIONALITY; 
SHIP    :    out    SHIP  CLASS; 
WEPS    :   out    MEAETINS  ; 
ECM    :    out    ECM    EQDIPMENT; 
METHOD    :    out    T!NGAGEMENT_METHOD)  ; 
end    THREAT; 
task    ENGAGEMENT   PLAN   is 

entry    ACCESS    EN  (TRACK    NDM     :    out    TRACK    NUMBER; 
PLAN    :    ouf^ENGAGEMEHT    PLAN)  ; 
end    ENGAGEMENT    PLAN; 
package   ENGAGE"HENT    DISPLAY   is 

procedure  AUTO    DISPLAY (TRACK    NUM    :    in    our   TRACK_NUMEEH; 
PLAN    :    in    oul    ENGAGEMENT    PlAN: 
HOSTILE    :    in    cut    HO STIIE    NAME; 
NATION    :    in    out    NATIONALITY; 
SHIP   :     in  out   SHIP    CLASS; 
WEPS    :    in  out   WEAPONS- 
ECM    :    in    out    ECM    EQUIPMENT; 
METHOD    :    in    out   "ENGAGEMENT   METHOD); 
procedure   MANUAL_DISPLA Y (TRACK^NUM    :    m   out 

101 


TRACK    NUMBER; 

PLAN    :   in    out    ENGAGEMENT    PLAN; 
HOSTILE    :     in    out   HOSTILE~NAME; 
NATION   :    in   out    NATIONALITY; 
WEPS    :    in    out    WEAPONS  ; 
ECM    :    in    out    ECM   EQUIPMENT; 
METHOD    :     in   out   ENGAGEMEN1_METH0D) ; 
crocsdurs   GRAPHICS; 
end    ENGAGEMENT   DISPLAY; 
end    DISPLAY; 
package    fcodv  DISPLAY    is 
■cask    body"  MENO_DIS  PLAY    is 
begin 

acceot    ACCESS    MEND(MENO     :    out    MENU   type)     do 
--    insert  addlticcal  body   of    ACCESS"   MENU 
end    ACCESS    MENU; 
--    insert    additional  body    of  task   MENU    DISPLAY 
end    MEND    DISPLAY; 

task    body    LAU NCHER_MISSIL E_STATUS    is 
begin 

accact    ACCESS    LM  (LAUNCHER    NBR    :    cut    LAU    NBR; 
CANNISTER    NER     :    out   CAN'NBR; 
MISS   -ype~:    out   MISSILE^type; 
INHIBIT    :     out    LAU    INHIBIT)     do 
--    insert   additicnal  body   of    ACCESS    LM 
end    ACCESS    LM: 
--    insert    additional  body    of    task    LAUNCHER    MISSILE   STATUS 
end    LADKCHER    MISSILE   STATUS; 
task    body    ENVIRONMENT    is 
begin 

accact    ACCESS    ENVJVIS    :    out    VISIBILITY; 
SEA    :    out    SEA    STATE; 
WINDDIR    :    OUt"WIND    DIRECTION; 
WINCSPD    :     out    WIND~SPEED; 
RELHUM    :     out    RELATIVE    HUMIDITY; 
TEtP    :    out    TEMEERATURI; 
BARPRESS    :    out    BAROMETRIC    PRESSURE; 
PRECIP    :    out    PEECIPIT  ATIOTI)     do 
--    insert  additional  body   of    ACCESS    ENV 
end    ACCESS    EN; 
--    insert    additional  body    of   task    ENVIRONMENT 
end   ENVIRONMENT; 
task    body    SHIP_PARAMETER    is 
beqin 

accact    ACCESS    SP(SHIP   COURSE    :    out    COURSE; 
SHIP    SPEED    T    out   SPEED; 
SHIP    LATITUDE     :   out    LATITUDE; 
SHIP'IONGITUDE    :   cut    LONGITUDE)     do 
--   insert  additional  body   of    ACCESS    SP 
end    ACCESS    S  P*  ~ 

--    insert    additional  body    of    task    SHIP    PARAMETER 
end    SHIP    PARAMETER; 
task    bcdv   TRACK   is 
begin 

accect    ACCESS   TR  (TRACK    NUM    :    out    TRACK    NUMBER; 
TRACK    TYP    :~out   TRACK    type;  ~ 

CLASS    :    out   VESSEL_CLlSS; 
RNG    :    out    HOSrange; 
BENG    :    out    BEARING; 
HOST    LAT    :    out    HOSTILE    LAT; 
HOST    ICNG     :    out    HOSTILE    LONG)     do 
--    insert  additicnal  body-cf    ACCESS    TR 
end    ACCESS    TR*  "" 

--    inserr   additional  body    of    task   TRACK 
end    TRACK  ; 
task    body    THREAT    is 
begin 

accent    ACCESS   TH  (HOSTILE    :    out    HOSTILE    NAME; 
NATION    :     OU^    NATIONALITY; 
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SHIP    :   out    SHIP  CLASS  ; 

WEPS    :    out    WEAFCNS; 

ECM    :    out    ECM    ECUIPMENT; 

METHOD    :     out    ENGAGEMENT_METHOD)     do 
--   insert   additional   body    of    ACCESS    TH 
end    ACCESS    TH; 
--    insert   additional  body    of   task   THREAT 
end   THREAT; 

task    body    ENGAGEMENT   PLAN    is 
beqin  " 

accept    ACCESS   EN  (TRACK    NOM    :     out    TRACK    NUMBER; 

PLAN    :    out    ENGAGEMENT    PLAN)     do 
--    insert  additional  boly   cf    ACCESS    EN 
end    ACCESS    EN; 
--    insert    additional  body    of   task   ENGAGEMENT  PLAN 
end    ENGAGEMENT   PLAN; 
oackage    body    ENGAGEMENT    DISPLAY    is 

croc€dure  AOTO    DISPLAY ( TRACK    NUM    :    in    out    TRACK    NUMEER; 

PLAN     :    in    OU^    ENGAGEMENT    PlAN; 

HOSTILE    :     in    out    HOSTILE'NAME; 

NATION   :    in   out    NATIONALITY; 

SHIP    :   in    out    SHIP   CLASS; 

WEPS    :    in    out    SEAPONS  ; 

ECM    :    in    out    ECM   EQUIPMENT; 

METHOD   :     in   out  I:ngAGEMENT_METHOD)     is 
beqin 

--   insert  additional  body    cf    procedure    AUTO   DISPLAY 
end    AOTC  DISPLAY; 
procedure  MANUAL   DISPLA Y (TRACK  NUM    :    in   out 

TRACK    NUMBER;    ~ 

PLAN    :    in    our    ENGAGEMENT    PLAN; 

HOSTILE    :     ll    out    H0STILE~NAME; 

NATION   :    in   out    NATIONALITY; 

WEPS    :    in    out    WEAPONS; 

ECM    :    in    out    ECM   EQUIPMENT; 

METHOD    :     in    out   ENGAGEMENI_METHOD)     is 
begin 

--   insert  additional  body    of    procedure    MANUAL    DISPLAY 
end    MANUAL    DISPLAY; 
procedure  GRAPHICS  is 
beqin 

--   insert  additional  body   cf    procedure    GRAPHICS 
end    GRAPHICS; 

--    insert   additional  body    of   package   ENGAGEMENT    DISPLAY 
end    ENGAGEMENT_DISPIAY; 
begin 

—    insert   additional   body  of    package    DISPLAY 
end    DISPLAY; 

cackace    LATA   BASE    MANAGER    is 
oackage    LM^STATUS     MANAGER    is 
type    NBR  LAUNCHERS; 

LAU    NEB   T   integer  range    1..NBR  LAUNCHERS; 
CAN   NBR    :    integer  range    1..4; 
MISS   tyoe    :    integer   range    1-.7; 
LAU    INHIBIT     :    boclean; 

task    LAUNCHER    MISSILE    STATUS   is 

entry   UPDATE    LAU  (LATJNCHER    :    in    LAU    NBR; 
CANNISTER    T    in    CAN    NBR; 
MISSILE    :    in   MISS    ^ype; 
LAUNCHER    INHIBIT    T    in      LAU    INHIBIT)  ; 
entry   ACCESS    LM(LAUNCHER    :    out    LAU    NBR; 
CAKNISTER    1   out    CAN    NBR; 
MISSILE    :     out    MISS  ^ype; 
LAUNCHES    INHIBIT     :~out    LAU    INHIBIT)  ; 
end   LAUNCHER'MISSILE    STATUS;      "" 
end    LM    STATUS    MA!?AGER;      "" 
package   SP  MANAGER    is 
tyoe    MAXSPEED; 
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CCUESE    :   integer    range    0..359; 
SPEED    :    integer    range   O..MaxSFEED; 
tyTJS    lATITUDE   is    record 

DEGREES    :    integer  range    -90..  90; 
MINUTES     :   integer  ranqe   0..60; 
SECONDS    :    integer  range   0,.60; 
end   record: 
type   LONGITUDE    is  record 

DEGREES    :   integer   range   -180.. 180; 
MINUTES    :    integer  rang??   0..60; 
SECONDS    :    integer  range   0..60; 
end   record; 
task    SHIP    PARAMETER   is 

entryUPDATE   SPfSHIP   COURSE   :    in   COURSE; 
SHIP    SPEED";    in   SPHED; 
SHIP"LATITUCE    :    in    LATITUDE; 
SHIP~LCNGITUDE    :    in    LONGITUDE)  ; 
entry  A'CCESS    SP(SHIP   COURSE    :    out    COURSE; 
SHIP    SPEED":   out    SPEED; 
SHIP~LATITUDE    :    out    LATITUDE; 
SHIP    LONGITUDE    :    out    LONGITUDE) ; 
end    SEIP^PARAMEIER; 
end    SP    MANAGER: 
cackace    SNVIRONHENI   MANAGER    is 

VISlEILITY    :    integer   range    0..30; 
SEA   STATE   :     inteoer   range    0..10: 
WIND   DIFECTICN    :    integer   range   0..359; 
WIND   SPEED    :    inteaer   range    0..100; 
RELATIVE  HUMIDITY    :    integer    range    0..100; 
TEMPERATURE    :    integer  range   -100.. 130: 
BAFCMETRIC    PRESSURE    :    integer   range    900.. 1000; 
PRECIPITATION   :     fccolean ; 
task    ENVIRONMENT   is 

entry  UPDATE   ENV (VI S    :    in   VISIBILITY; 
SEA   :    in    SEA   STATE; 
WINDDIR    :     in~WIND    DIRECTION; 
WINDSPD    :     in   WIND~SPEED; 
RELHUM    :     in    RELATIVE    HUMIDITY; 
TEMP    :     in    TEMPERATURE; 
BARPRESS     :    in    BAROMETRIC   PRESSURE; 
PRECIP    :     in    PRECIPITATIO!T)  ; 
entry  ACCESS    ENV  (VIS    :    out   VISIBILITY; 
SEA    :     out    ^EA    STATE; 
WINDDIR    :     oufWIND    DIRECTION; 
WINDSPD    :    out    WINC"SPEED; 
RELHUM    :     out   RELATIVE    HUMIDITY; 
TEMP    :    out    TEMPERATUR'E: 
BARPRESS    :     cut    BAROMETRIC    PRESSURE; 
PRECIP    :    out    PRECIPITATION)  ; 
end   ENVIRONMENT; 
end    ENVIRONMENT    MANAGER; 
oackaqe    THREAT    MANAGER    is 
HOSTILE    NAME' 
NATIONALITY 
SHIP    CLfiSS 

WEAPONS    :   String  (i:;50)  :'  ■ 
ECM    EQUIPMENT   :     string ( 1 .. 50)  ; 
ENGAGEMENT    METHOD    :    str  ing  (1  .  .50)  ; 
task    THREAT    is 

entry   ACCESS    TH(HOSTILE    :    out    HOSTILE    NAME; 
NATION    :    out    NATIONALITY; 
SHIP    :    out    SHIP   CLASS; 
WEPS     :    out    WEAPONS; 
ECM    :     cut    ECM    EQUIPMENT; 
METHOD    :    out   ENGAGEMENT    METHOD); 
end   THREAT; 
end    THREAT    MANAGER; 
package   TRACK    MANAGER   is 

TRACK   NUMBEl   :    integer    range    100.. 3199; 
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T     HANAbJiK     IS 

E~:    string  M  . .  1  2)  ; 

:    string]1.  .  10)  ; 
:    str ing( t. .  9)  ; 


TBACK  type    :    integer   range    1..7; 
VZSSEI   CLASS    :    integer    range   0. .  1 ; 
•^ype   MAXrange; 

HCSrange   :    integer  range   0.. MAXrange; 
BEARING    :    integer  range    0..359; 
type    HOSTILE_LAT    is   record 

DEGREES    :    integer  range   -90.. 90; 
MINOTES     :    integer   range   0..60; 
SECONDS    :    integer  range   0..60; 
end   record  ; 
type    HOSTILE   LONG   is   record 

DEGREES    :   integer  range   -130.. 180; 
MINUTES    :    integer  range   0..60; 
SECONDS    :    integer  range   0..60; 
end   record; 
task    TRACK    is 

entry   ADD(TRACK    NUM     ;    in    TRACK    NUMBER; 
TRACK    TYP    :    in   TRACK    type;      " 
CLASS~:    in    VESSEL_CLISS; 
RNG   :    in    HCSrange; 
BRNG     :    in    BEARING; 
HOST    LAT     :    in    HOSTILE    LAT; 
HOST    LONG     :    in    HOSTILE    LONG); 
entry  DELETE  (TBACK    NUM    :~in    TRACK    NUMBER; 

TRACK    TYP    :    in   T5ACK    type)  ; 
entrv   ACCESS    IR(TRACK   HUM    :    our    TRACK    NUMBER; 
TRACK    TYP   7  out    TRAtK   type; 
CLASS":    out    VESSEL   CLiSS; 
RNG    :    out    BCSrangeT 
BRNG    :    out    BEARING; 
HOST    LAT     :    out    HOSTILE   LAT; 
HOST~LONG     :    out    HOSTILE    LONG)   : 
entry  UPDATE   TY(TRACK    NUM":    in    TRACK    NUMBER 

TRACK    TYP    T   in   TRAClT    type)  : 
entry   UPDATE    CL(TRACK   TIUM    :    m    TRACK    NUMBER 

CLASS     :    in'VESSEL    ClASS)  ; 
entry   UPDATE    RN(rRACK_NUM    :    in    TRACK_NUMBER 

RNG   :    in    HCSrange)  ; 
entry   UPDATE    BR(TRACK    NUM    :    in    TRACK    NUMBER 

BRNG     :    in    lEARING)  ;" 
entry   UPDATE    IA(TRACK    NUM    :    in    TRACK    NUMBER 

HOST    LAT    :"in    HOSTIIE    LAT): 
entry  UPDATE    LO(TRACK    NUM    :    m    TRACK    NUMBER 
HOST    LONG    T    in    HOSTILE    LONG); 
end    TRACK;" 
end    TRACK    MANAGER; 
package    MENU    MANAGER  is 
type   MENU  type; 
task    MENU    is 

entry   ACCESS    ME  (MEND    TY    :    out    MENU    tyoe)  ; 
end    MENU;  ~  "  "      * 

end    MENU    MANAGER; 
package    ENGAGEMENT    PLAN   MANAGER    is 

TRACK   NUMBER    :    integer    range    100., 3 199; 
ENGAGEMENT    PLAN    :   strin  g  (1 . .  50)  ; 
HOSTILE   NAME   :    string M  ..  1  2)  ; 
NATIONALITY    :   string  M.  .  1 0)  ; 
SHIP   CLASS    :    stringt  >. .  9)  ; 
WEAPONS    :    string  (1.. 50)  : 
ECM    EQUIPMENT    :    string ( 1. . 50) ; 
ENGAGEMENT    METHOD    :     str ing  (1 . . 50)  ; 
task    ENGAGEMENT   PLAN    is 

en^-ry   ACCESS    "ENrTRACK    NUM    :    out    TRACK    NUMBER 
PLAN     :    OUfENGAGEMETIT    PLAN; 
HOSTILE    :    out    HOS  TILE"NAME; 
NATION    :     out    NATIONALITY; 
SHIP    :    out    SHIP   CLASS; 
MEPS    :    out    WEAPONS: 
ECM    :    out     ECM^EQUIPMENT; 
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METHOD    :     out   ENGAGEMENT    METHOD)  ; 
end    ENGAGEMENT    5LAN; 
and    ENGAGEMENT    PLATJ    MANAGER; 
end    DATA    BASE   MANAGEET 
paclcage    body   DATA    BASE   MANAGER    is 
package    body    LM   STATUS    MANAGER    is 

task    body    LIO NCHER^MI SSILE_STATUS    is 
beqin 

accspt    OPDATE   LAU  (LAUNCHER    :     in    LAU    NBR; 
CANNISTER     :'in    CAN    NBR; 
MISSILE    :    in   MISS    ^yps; 
LAUNCHER_INaiBIT    1    in      LAO    INHIBIT)     do 

—  insert  additional  body   of  "UPDATE   LAU 
end    UPDATE    LAU; 

accept    ACCESS   LM  (LAUNCHER    :    out    LAU    NBR; 
CANNISTER     :~out    CAN    NBR; 
MISSILE    :     cut    MISS    rype; 
LAUNCHER     INHIBIT    :"out    LAU    INHIBIT)     do 

—  insert   additional   body   of" ACCESS   LM; 
end    ACCESS    LM; 

end    LAUNCHER3.MISSILE    STATUS; 
begin  " 

--    insert   additional  body    of   package  LM    STATUS    MANAGER 
end    LM    STATUS    MANAGER;       -«  ^  ^  - 

packaoe   body    SP  MANAGER  is 
task    body   SHIP    PAEAMETER   is 
b€gin 

accent  UPDATE    SE(SHIP    COURSE    :    in    COURSE;    ' 
SHIP   SPEED    T    in    SPEED; 
SHIF"LATITUDE    :    in    LATITUDE; 
SHIP~LONGITUDE    :    in    LONGITUDE)     do 
--    insert    additional   body   of   UPDATE   SP 
and    UPDATE   SP; 

accept  ACCESS    SP(SHIP    COORSE    :    out    COURSE; 
SHIE   SPEED    T    out    SPIED; 
SHIP~LATITUDE    :    out    LATITUDE; 
SHIP_LONGITUDE    :    out    LONGITUDE)     do 
--   insert    additional    body   of   ACCESS    SP 
end   ACCESS    SP ; 
end    SHIE   PAElMETEE; 
baain 

--    insert   additional  body    of   package   SV   MANAGER 
end    S?    MANAGER; 

Dackaae   body    ENVIRCNMENT    MANAGER   is 
task    body    ENVIECNMENT    is 
begin 

accept    UPDATE  ENVfVIS    :    in    VISIBILITY; 
Stli    *     ■'n    SEl   STATE* 

■  HiNDDiR  :    in~wiND  Direction; 

WINDSPD    :     in    WIND"SPEED; 
RZIHUM    :    in    RELATIVE    HUMIDITY; 
TEMP    :    in    TEMPERATURE; 
BARPRESS     :    in    BAROMETRIC  PRESSURE; 
PRECIP    :     in   PRECIPITATIUN)     do 

—  insert   additional   body   of    UPDATE  ENV 
end    UPDATE    ENV; 

accept    ACCESS  ENV(VIS    :    out    VISIBILITY; 
SEA    :    out    SlA   STATE; 

WINDDIR     :    out    WIND    DIRECTION; 
WINDSPD     :   out    WINC'SPEED: 
RELHUM    :     cut    RELATIVE    HUMIDITY; 
TEMP    :    out  TEMPERATURE; 
BARPRESS    :    out    BAROMETRIC    PRESSURE; 
FRECIP    :    out    PRECIPITATIOK)     do 
--    insert  additional  body  of    ACCESS   ENV 
end    ACCESS    ENV; 
end   ENVIRONMENT; 
begin 
—    insert   additional  body   of   package   ENVIRONMENT_MANAGER 
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end    ENVIRONMENT    MANAGER; 
packaqe   bcdy    THHEAT   MANAGER    is 
task    body    THREAT  is 
beain 

accept    ACCESS   TH  (HOSTILE    :    out    HOSTILE    NAME; 
NATION    :    OU^    NATIONALITY; 
SHIP    :    out    SHIP   CLASS; 
WEPS    :     cut    WEAPONS; 
ECM    :    out    ECM    EQUIPMENT; 
METHOD     :    out   ENGAGEMENT    METHOD)     do 

—  insert   additional   body   ofACCESS   TH 
end    ACCESS    TH; 

end    THREAT;   " 
begin 

—    insert    additional  body    of    package   THREAT    MANAGER 
end    THREAT   MANAGER; 
packaqe    body    TRACK    MANAGER   is 
task    body    TRAC"R  is 
begin 

accept    ADD  (TRACK    NO  M    :    in    TRACK    NUMBER; 
TRACK    TYP    :    in~TRACK   type; 
CLASS":    in    VESSEL    CLlSS; 
RNG   :     in    HOSrangeT 
EFNG     :    in     HEARING; 
HOST    LAT    :     in    HOSTILE    LAT; 
HCSr_LCNG     :    in    HO  STIL"E_LONG)     do 

—  insert  additional  bcdy   of    ADD; 
end    ADD: 

accept    DELETE  (TRACK    NUM    :    in    TRACK    NUMBER; 
TRACK_TYP    :    in    TRlCK_type)     do 

—  insert  additional  bcdy  of    DELETE 
end    DE  L  E  TE  * 

accept    ACCESS   TR  (TRACK    NUM    :     out    TRACK   NUMBER; 
TRACK    TYP    :~out   TRAC7    type; 
CLAS"5    :    out    VESSEL_CIASS; 
RNG    :    out    BOSrange; 
BPNG     :    out    BEARING; 
HOST    LAT     :   out    HOSTILE   LAT; 
HOSTILONG    :    out    HOSTILE    LONG)     do 

—  insert    additional    body~of    ACCESS    TR 
end  ACCESS    TR; 

accept     UPDITE   TY(TRACK    NUM    :     in    TRACK   NUMBER; 
TRACK_TYP    :"in   TRACK~-^ype)     do 

—  insert    additional  bcdy  of    UPDATE   TY 
end  UPDATE    TY; 

accept    UPDIIE  CL(TRACK    NUM    :    in    TRACK   NUMBER; 

CLASS    :    in  VESSEL    CLlSS)     do 
--    insert    additional  body  of    UPDATE   CL 
end  UPDATE    CL; 
accept    UPDATE    RN(TRACK_NUM    :     in    TRACK_NUMBER ; 

RNG    :    in    HCSrange)    do 

—  insert    additional   body  of   UPDATE   RN 
end  UPDATE    BN; 

accept    UPDITE   BR  (TRACK    NUM    :    in    TRACK   NUMBER; 
ERNG     :    in    EEARINGi     do 

—  insert    additional  bcdy   of    UPDATE   TR 
end  UPDATE    TB; 

accent    UPDiTE   LAfTRACK    NUM    :    in    TRACK   NUMBER; 
HOST_LAT     :    in    HOSTILE    LATJ.    do 

—  insert   additional  bo3y  of    UPDATE   LA 
end  UPDATE    LA; 

accent    UPDiTE   LO(TRACK    NUM    :     in    TRACK   NUMBER; 
HOST_LONG    :"in    HOSTIlE    LONG)     do 

—  insert    additional   body  of   UPDATE   LO 
end  UPDATE    10; 

end  TRACK; 
begin 

--  insert  additional  body  of  package  TRACK  MANAGER 
end  TRACK  MANAGER; 
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package    body    MENU    MANAGER    is 
task    body    MENU   is 
beqin 

accept       ACCESS    ME(MENU    TY    :    oui:    MENU    type)     do 
—    insert  addi'Eional  body   of    MENU 
end    ACCESS    ME; 
end    MENU; 
beain 

--    insert   additional  body    of   package  MENU   MANAGER 
end    MENU    MANAGER; 

packaae    body    ENGAGEMENT    PLAN    MANAGER    is 
task    body    ENGAGEMENT    PLATJ   is 
beqin 

accept    ACCESS   EN  (TRACK    NUM    :     oat   TRACK   NUMBER; 
PLAN     :    out    INGAGEMENT    PLAN; 
HOSTILE    :     cut    HOSTILE"NAME; 
NATION    :     out    NATIONALITY; 
SHIP    :    out    SHIP    CLASS; 
WEPS    :    out    WEAPONS; 
ECM    :    out    ECM    EQUIPMENT; 
METHOD    :     out   ENGAGEMENT    METHOD)     do 
—   insert    additional    body   of    ACCESS    EN 
end  ACCESS    EN; 
end    ENGAGEMENT_ELAN; 
beqin 

--    insert   additional  body    of   package 
—     ENGAGEMENT    PLAN    MANAGER 
end    ENGAGEMENT.PLAH.MANAGER; 
begin 

—   insert   additional   body   of   package    DATA    BASE  MANAGER 
end    DATA    BASE   MANAGER; 
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